RE: Setting up user security on development machine

Aaron,

Technically, a developer doesn't need any special authorities.

One exception I've run into (while debugging from WDSC ??) was the need
for *SERVICE.

You might set up a test developer profile and see what you can do.

Certainly you don't want to give them *ALLOBJ or *SPLCTL.

HTH,

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx 
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of albartell
Sent: Monday, November 20, 2006 11:03 AM
To: 'Midrange Systems Technical Discussion'
Subject: Setting up user security on development machine

Hi all,
 
I have been doing a lot of reading at the following link:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.js
p?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.