|
Thanks for the explanation. Been awhile since I was that low. Actually a machine never lasted a day in our shop after being plugged in before going to level 30 or higher. Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Al Barsa <barsa@xxxxxxxxxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 09/04/2003 04:43 PM Please respond to Midrange Systems Technical Discussion To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> cc: Fax to: Subject: Re: Going to level 30 Security Rob, The way IBM implemented level 20 was to add additional authorities whenever you create a user profile. For sure one of them is *ALLOBJ, and I think that there's another. For Kirk, you can see what they are by creating a user profile. As you create one at level 20, an implicit CHGUSRPRF occurs to add that authority, and a completion message is sent from the action of that change. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com rob@xxxxxxxxx Sent by: midrange-l-bounce To s@xxxxxxxxxxxx Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> 09/04/2003 05:18 cc PM Subject Re: Going to level 30 Security Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> At level 20, does removing *ALLOBJ from somebody actually do anything? Wouldn't the theory actually be: 1) Make sure that everyone has *ALLOBJ. 2) Jump to plus 20 3) Remove *ALLOBJ from one putz. See what cr@ps out. Either fix the object with authorization lists or groups. Then do the department, etc. I am guessing that he's not in a shop that has time to use "application level" security. Which, translated, means that no one has access to any data. All data access is done by programs which adopt authority. When implementing plus 20, you might want to follow these steps. I used this is a shop supporting multiple group profiles, etc Create three authorization lists: groupnameF, groupnameO, groupnameQ, and if you keep source on the production machine groupnameS. Samples include: SSA30F, SSA30O, SSA30Q, SSA30S. In these authorization lists *PUBLIC has *EXCLUDE. SSA30F, the users who need data access have *ALL. Sometime, somewhere, you'll run across a reorg or something that will requires *ALL. *CHANGE has never worked. SSA30O, users have *USE, development has *ALL. SSA30Q, users who just run queries have *USE, users who modify queries have *ALL. SSA30S, development has *ALL, no one else has access. On your file library: CHGLIB LIB(filelib) CRTAUT(SSA30F) CHGAUT OBJ('/qsys.lib/filelib.lib') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE) CHGAUT OBJ('/qsys.lib/filelib.lib') AUTL(SSA30F) CHGAUT OBJ('/qsys.lib/filelib.lib/*') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE) CHGAUT OBJ('/qsys.lib/filelib.lib/*') AUTL(SSA30F) On your object library: CHGLIB LIB(objlib) CRTAUT(SSA30O) CHGAUT OBJ('/qsys.lib/objlib.lib') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE) CHGAUT OBJ('/qsys.lib/objlib.lib') AUTL(SSA30O) CHGAUT OBJ('/qsys.lib/objlib.lib/*') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE) CHGAUT OBJ('/qsys.lib/objlib.lib/*') AUTL(SSA30O) On your Query library: CHGLIB LIB(qrylib) CRTAUT(SSA30Q) CHGAUT OBJ('/qsys.lib/qrylib.lib') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE) CHGAUT OBJ('/qsys.lib/qrylib.lib') AUTL(SSA30Q) CHGAUT OBJ('/qsys.lib/qrylib.lib/*') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE) CHGAUT OBJ('/qsys.lib/qrylib.lib/*') AUTL(SSA30Q) On your source library: CHGLIB LIB(sourcelib) CRTAUT(SSA30S) CHGAUT OBJ('/qsys.lib/sourcelib.lib') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE) CHGAUT OBJ('/qsys.lib/sourcelib.lib') AUTL(SSA30S) CHGAUT OBJ('/qsys.lib/sourcelib.lib/*') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE) CHGAUT OBJ('/qsys.lib/sourcelib.lib/*') AUTL(SSA30S) After all this is completed, jump to plus 20. Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Al Barsa <barsa@xxxxxxxxxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 09/04/2003 04:01 PM Please respond to Midrange Systems Technical Discussion To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> cc: Fax to: Subject: Re: Going to level 30 Security The audit journal will only help you going to level 40. Depending on he complexity of the shop, you can revoke *ALLOBJ from one key user per department, and if that doesn't break everything, then the entire department. Go about doing this one department at a time. Once you've done the entire company, you can change QSECURITY to 30 and re-IPL. Remember, every user that's not supposed to have *ALLOBJ normally will have it revoked in that IPL, so make sure that you have QSECOFR's password. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com kirkg@xxxxxxxxxxx om Sent by: To midrange-l-bounce midrange-l@xxxxxxxxxxxx s@xxxxxxxxxxxx cc Subject 09/04/2003 04:43 Going to level 30 Security PM Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> It been a long since I've needed to do this... I thought I remembered there was a way to use the audit journals to test what will happen when you move from security level 20 to 30 or higher. I've been able to find a tip that says basically going 20 to 30 is by setting up test profiles. I've also found a tip of going from 30 to 40 that does use the audit journal using the *PGMFAIL option. Is there a better way to get from 20 to 30 other than by trial and error? _____________________ Kirk Goins CCNA Systems Engineer, Manage Inc. IBM Certified iSeries Solutions Expert IBM Certified iSeries e-Business Infrastructure IBM Certified Designing IBM e-business Solutions Office 503-353-1721 x106 Cell 503-577-9519 kirkg@xxxxxxxxxxxxx www.manageinc.com _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-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.