Re: Enforcing Read Only Access on files open for maintenance

GKern@xxxxxxxxxxxxxxxx wrote:

"Any user that has *USE access to these files and attempts to use an
existing program that opens one of these files with update, that program
will error out with invalid authority."

I need to avoid that (obviously).

"If any of these programs have adopted authority, bang goes you security."

I just tested using read only access, but adopted authority 'broke' that theory. The next test was to issue OVRDBF to specify *INHWRT = YES and that did seem to work. Since there will be less than 100 objects in the Purge library, it might be practical to issue OVRDBF *INHWRT = YES whenever they add the purge library to their library list (and then delete the overrides when the remove the purge library). I'm not sure about SQL updates... but we only have a few programs that do SQL updates and those could be included in the purge library and compiled with commit = Yes to prevent them from doing their updates.

Jerry:

The combination of requirements makes it tricky. You don't want to change any programs, but you don't want authority errors interfering with how things run. The *INHWRT gives the appearance of working, so no program changes are needed -- but that doesn't relieve the actual authority problem because the ability to update the files exists whenever the override isn't in effect.

And you want the override in effect _only_ when the library target is PURGELIB (or whatever its name is). When any other library is being accessed, the override for those files should _not_ be in effect.

Two elements seem reasonable:

1. Control access to the *library* at the very least. Allow access only through an option that sets overrides at entry and removes them on exit. The option would also adopt authority for the library.

I have no idea what your application structure is nor what access is granted to command-lines, <Attention> programs, etc.; but without some general authority restriction, there seems no hope.

2. Also consider creating a journal just for the files in that library and creating at least a generic trigger program for the files. In the event that some update does happen, the journal can be used to set everything back. If no updates happen, then there'll be minimal impact, neither for performance nor space. No harm, no foul.

But if a change does get executed through some unexpected/unprotected means, a generic trigger could send a signal to a responsible administrator (or many of them). Send a message, send an e-mail, send notices that changes need attention to be backed out. You could also send (break?) messages out to the workstation if it's interactive, saying "You're updating our history! Stop it! Don't change the past."

A journal for recovery and trigger monitoring would both be useful for *ALLOBJ or other accidents.

Tom Liotta