This morning a customer of mine had a problem. A user that generally shouldn't be allowed to do anything other than order entry accidentally started the daily close. QINTER shut down and the backup started and it was a bit of a mess.

The security scheme in place is basically a leftover from the 80s: SECLVL is 20 and almost every user has USRCLS(*SYSOPR) and *ALLOBJ and *SAVSYS special authorities. As you might imagine, this can lead to some rather unhappy scenarios.

On our test system we have SECLVL 40 and user profiles are either *USER or *PGMR with no special authorities. We want to find out what potential problems might exist by moving our customers to the same. We're also experimenting with different object ownership and object authority schemes. Currently we have all file and program objects owned by a single user (ERA) and *PUBLIC authority set to *USE. User profiles have ERA in the group profile. User ERA has *ALL authority to the objects it owns.

What I'm wondering is what ownership and authority schemes do others use? It occurs to me that with every user profile having ERA in the group and user ERA having *ALL authority to the object, isn't that the same as giving *ALL authority to the users? If I remove ERA from the group profile, then the users will access the objects with *PUBLIC access rights which are set to *USE, which I think means the data rights are read only, no update or delete. That would create a problem for users.

James Rich

if you want to understand why that is, there are many good books on
the design of operating systems. please pass them along to redmond
when you're done reading them :)
- Paul Davis on ardour-dev

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].