Prevent User Profile from using public authority
"Wilt, Charles" <CWilt-GqJsjaCkv4dWk0Htik3J/[email protected]>
| Newsgroups | gmane.comp.systems.as400.security |
|---|---|
| Message-ID | <[email protected]> |
All, Is there any way to prevent a user profile from using *PUBLIC authority? Here's the scenario, I've got a user profile set up for JDBC use from a external web server. All I want this profile do be able to do is call stored procedures it is specifically authorized to. Basically, I'm concerned about *PUBLIC being expand from just "regular" users, ie. company employees, to the entire world; or at least those non employees who have logons for the web server or more worrisome, hackers that manage to breach the web server (Windows based, not by my choice ;-) I've thought of two ways to handle this. 1) a. Create a group profile for all my "regular" users. b. Grant the group profile the same authority that *PUBLIC currently has for each & every object c. change *PUBLIC to *EXCLUDE for every object 2) a. Grant *EXCLUDE authority to every object for this user profile (or better yet a new group profile of which this profile will be a member) Don't forget that when I say "every object" I'm talking about IFS files and directories too. Couple of problems: 1) Making sure new objects on the system get the correct authorities. 2) I'd imagine that there are IBM objects I shouldn't set *EXCLUDE What I'd really like is to be able to do a CHGUSRPRF USEPUBLIC(*NO). But that parm doesn't exist <grin> So how do you handle this? Thanks, Charles Wilt iSeries Systems Administrator / Developer Mitsubishi Electric Automotive America ph: 513-573-4343 fax: 513-398-1121 _______________________________________________ This is the Security Administration on the AS400 / iSeries (Security400) mailing list To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected] To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/security400 or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected] Before posting, please take a moment to review the archives at http://archive.midrange.com/security400.