Re: Setting up user security on development machine

[Mike <koldark@xxxxxxxxx>]

Of course no one can have *ALLOBJ or *SECADM.

Validation Lists and groups are your friend in this case Aaron.

For the excluded library, I would create a group with the same name and only
allow that group to that library. On the library obj authority, assign a
validation list and *PUBLIC will be *VLDL (or something like that). In the
validation list make sure to exclude *PUBLIC

Have a group and of course a validation list for the "general" libraries

Then for the NDA projects. Create a seperate outq in the secured libl and
make sure that is secured as well.

IM if you have further questions. My brain dump isn't working too well right
now and I am sure that others will have other opinions.

On 11/20/06, albartell <albartell@xxxxxxxxx> wrote:
> Hi all,
>
> I have been doing a lot of reading at the following link:
>
> http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rbapk
> /rbapkpart.htm
>
> I am looking for the best approach in applying security to a development
> machine where I will have a small handful of trusted in-house developers
> working on it and then also the occasional consultant.
>
> Known Requirement #1
> At times there will be projects where an NDA is signed and work for that
> project will be done in a particular library (possibly contain some of the
> customers code that we are interfacing with).  Without going into the
> details of a particular NDA I am dealing with, one of my requirements will
> be to lock down this library so only the programmer that is working on it
> has access to it.  This would then also include only allowing that
> programmer to view their spool files (compile results).
>
> Known Requirement #2
> For when I have occasional consultants on the machine I would only want
> them
> to be able to operate in the library I gave them access to and not other
> libraries or spool files.
>
> Right now I am at security level 40 which from what I read seems to be the
> right fit (level 50 looks to be over the top for my needs).  My basic
> needs
> are to allow one group of people access to most all libraries except a
> few,
> and the opposite of that, allow access to a single library/splf's and
> nothing else.  From what I understand I do not want to give out *ALLOBJ
> authority because then people can just grant authority to themselves if
> they
> don't have authority to something.  I don't want to hand out *IOSYSCFG
> even
> though that would be handy for programmers when they need to do stuff with
> the HTTP *ADMIN server.  I am basically looking for a solid combination of
> authorities that a typical programmer profile should have.
>
> The aforementioned link gives a lot of good info, and I am learning a lot,
> but I have yet to find a "best practices" or tutorial type approach to
> implementing user profile security for OS/400 objects/commands.  Are there
> any that someone could suggest?
>
> TIA,
> Aaron Bartell
> --
> 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.