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.
This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact