Re: Trigger programme without a trigger.

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

CRPence wrote:
> However it takes 
> only that one person using either a special profile or a special tool 
> that gives the developer or implementor all-access to /fix something/, 
> or an accidental equivalent granting of rights to a user due to error(s) 
> in security implementation, for the expected access method to be 
> bypassed on the production system; such a bypass need not even be 
> malicious.
>   
This is a bit of a red herring, because if you can bypass authority then 
you can bypass triggers: all it takes is an "accidental" RMVPFTRG.  If 
your environment is such that people have access to high security 
profiles, then there's no way to protect your data.  Your accidental 
granting of rights is equivalent to accidentally granting QSECOFR 
rights; no amount of security can prevent you from a security failure 
that egregious.

Basing your architecture on the fact that you can't enforce your own 
security rules seems to me to be a bad way to do things.


>    FWiW I also prefer that the owner of the database to be a peon user, 
> so that any program adopting the authority of that owning user, for the 
> purpose of accessing the database, does not also obtain access to 
> anything beyond what the active user for the job is already authorized.
>   
Agreed.  The owner of the database ought have no authority except to the 
data.  That's what they do, and that's all they do. 

Joe



Editorial note:
> > Now, if you absolutely must,
> > you can grant read <ed: "access" inferred vs "writes"> writes
> > so people can do external queries.  That's up to you.  But there is
> > simply no reason to have unfettered update writes to your database.
> > If you've created a perfectly good database access mediator such as
> > the I/O module mentioned, then by all means lock the database down -
> > you will have shut the door on a lot of gremlins.
> >
> >     
Actually I somehow managed to type "writes" twice instead of "rights".

Joe