Re: Trigger programme without a trigger.

I agree. It is possible and reasonable to expect that within a production environment, that it *can* be made generally safe to _assume_ unilateral access by only the intended application(s). 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.

My $.02 offered tends toward alluding to the caveats, for possibility of failed assumption(s), but not with intent to imply that such control is not possible in any specific case. My warning serves as notice, that care should be taken, to ensure that all assumptions are validated. I even offered that the open exit could be used to prevent the file even being opened if not negotiated\performed by the expected application, to further improve the ability to limit access to only the desired. And as an open trigger [if obtained for example as a design change] then even the renamed file remains protected just as a file with an I/O trigger; not as easy a task, for a user implemented trigger.

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.

Regards, Chuck

Joe Pluta wrote:

CRPence wrote:

Since there is only a limited ability to ensure that the given assumption [that all I/O is via only one program] can be met,

<<SNIP>>

Anyway, it troubles me when i developers say that they can't control
access to files. You most certainly can, especially in production.
It's quite simple: you create a user profile that nobody else has
access to. That high-security access (HSA) profile owns the
database, lock stock and barrel. Nobody else has any rights to the
data. The I/O module then adopts that user profile.

Done.

Unless somebody circumvents this by somehow running under the HSA profile (which is a termination offense equivalent to unauthorized QSECOFR access), then the data is entirely secured to that program.

Yes, it stops programmers from doing quick DFUs. As well it *should*
in a production environment. If you need regular DFU patches to your
production database, that's a symptom of a much larger problem.

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.

Just a half a nickel from me.