[AccessD] Cascade-delete (was: Estimating Help)

John W. Colby jcolby at colbyconsulting.com
Mon Feb 10 06:34:00 CST 2003


Whatever.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-admin at databaseadvisors.com
[mailto:accessd-admin at databaseadvisors.com]On Behalf Of Gustav Brock
Sent: Monday, February 10, 2003 3:30 AM
To: John W. Colby
Subject: Re: [AccessD] Cascade-delete (was: Estimating Help)


Hi John

This has nothing to do with cascade deletes or not. It's about, in
general, as a trusted user to leave the application open free to use
by a non authorized person - the cleaning man in your specific case.
Quite a few places you'll get fired for doing that.

If the specifications told that this application would be operated by
skilled and authorized people only, you cannot blame the developer for
the above case.

If the specifications tell that access to data other than through the
application must not exist, you apply security. Even for Jet this is
quite straightforward. By simply applying a password to the backend
the "clueless" user is locked out; if you wish to block the
not-so-clueless user, encrypt the backend; if tight security is
needed, apply Jet security. If even tighter security is requested,
move to an SQL engine like Oracle with documented security.

If a user tries to circumvent these precautions, he's acting like a car
thief.

/gustav


> What you are trying very hard to ignore is that the car can be stolen,
that
> the car can be legally borrowed by someone not intimately familiar with
the
> way it operates etc.

> I make no argument that turning off cascade delete magically locks up an
> application, it doesn't.  However it does, absolutely and 100% effectively
> prevent a clueless person from ripping thousands of records out of the db
> with a single keystroke.  Your application is NOT the only way to get at
the
> data.  If it were your arguments might hold more water.  As it is, they
leak
> like a sieve.

> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com


>>>As a general note, it's the responsibility of a trusted user to not pass
>>>his/her access to an application to another user granted lower
>>>rights to that application and its data.

>> That's about like the car company saying "it's the responsibility of the
>> driver not to have an accident", when faced with liability for not
>> providing
>> safety mechanisms.  Absolutely true, but completely irrelevant.

> No it's not like that. It's like a father passing the car keys to his
> twelve year old son. That's not the responsibility of the car
> manufacturer.

> As a user with admin rights you left your application free to use by a
> non skilled user with no admin rights - no developer can prevent that
> other than secure every single operation with some kind of
> authorization like a request for a password or a fingerprint. Such a
> system is relevant for applications launching nuclear fireworks and the
> like but not for the daily work with business applications.

> For specific and seldom operations, however, it can be OK; I have seen
> an accounting application which asked you to type in D-E-L-E-T-E to
> approve you really wanted to delete a financial year and all its data.

> Reading Rocky's post on this, it's something like that he's talking
> about.

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com






More information about the AccessD mailing list