|
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-2025 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.