|
While I have no doubt that this approach works in yours (and probably other) environments, the gaping hole you speak of may lay in some "unauthorized" persons ability to execute one of these programs. As the program executes as *OWNER, OS/400, as you pointed out, doesn't enforce any authorities on the objects used by the individual executing the program. In this case, it's not the "inclusion" of users that would concern me but the "exclusion" of individuals. What I find more concerning is the use of QPGMR. As this is an IBM-supplied profile, creating all programs to adopt these permissions is more dangerous than your approach (i.e. creating a specific profile). Working in a highly regulated industry, we are subjected to annual audits by the FRB and SEC. One of the items that is reviewed without hesitation is the identification of programs that execute under adopted authority. This review is NOT limited to just QSECOFR. Our solution is the use of Group Profiles. Where as, we create programs and files with specific ownerships based upon the application. Individual users are than "added" to the group "owning" the objects. This enables us to have users enrolled in 1 group, 2 groups or no groups (i.e. exclusion). Now before anyone says you can do the same by "revoking" permissions to the qualified objects, we prefer to operate on the "need to use basis", where you are granted access based on your need to use. In other words, we don't want to have to "revoke" access to everything we create. With 300+ users, this approach works best in our environment while (most importantly) satisfying regulators. Hope this feedback is helpful. MichaelR -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Pete Helgren Sent: Tuesday, March 23, 2004 12:09 PM To: RPG programming on the AS400 / iSeries Subject: RE: Object authority Actually, I think this is a great approach and until I see some gaping hole in my logic, we'll continue to use it. I don't know if there is an equivalent in the Windows and Linux world, but when I finally discovered this as part of OS/400 security I was relieved. It is very easy to implement. We don't use QPGMR, we create a specific User Profile, but all programs are compiled USRPRF(*OWNER) and the files and objects are owned by this profile. The beauty is (as mentioned before) that users sign on to the iSeries and get a menu driven system that allows them to run any program because they *are* the owner as far as the iSeries is concerned. If they exit the menu system (Sys Attn or whatever), they revert back to their own user profile which in some cases can do nothing. This seems to be a fairly rational and easy approach to managing security. Or, perhaps I missed something. Pete Helgren Value Added Software,Inc. 801.581.1154 -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Rooney, Michael P Sent: Tuesday, March 23, 2004 9:09 AM To: RPG programming on the AS400 / iSeries Subject: RE: Object authority If your shop only has 1 user this works well. Better yet, why not run as QSECOFR? Otherwise, I vote to stay as far away from this approach as possible. -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Gerald Magnuson Sent: Tuesday, March 23, 2004 10:50 AM To: RPG programming on the AS400 / iSeries Subject: RE: Object authority how about another survey question??? We have changed the CRTPGM (all create pgm commands) to USRPRF(*OWNER) and all programs are created with QPGMR group... How many of us are running this way, instead of the actual user profile controlling both the program object authority and data object authorities??? ("make it work like the S/38,S/36,S......") -- Gerald Magnuson The Knapheide Manufacturing Company Quincy Illinois _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
