Security on the i strangeness
Last Post 15 May 2013 01:26 PM by Lennea Kernaz. 6 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Lennea Kernaz
Basic Member
Basic Member
Posts:89

--
31 Jan 2013 03:11 PM

I think of myself as quite knowledgable on the security of the iseries but something is really stumping me here.  I am currently tightening up security on our development box and there is something very strange going on and it seems to be related to one of our "owning" profiles.  The administrators are part of a group "GRPITIMPL" so that user profiles created are owned by this profile.  The only members of this group are the few administrators.  We also have a "OWNIT" group profile  that is the owner of any of our development objects (programs and such that go to production).  This group is identical to the GRPITIMPL group profile but has no members.

I wanted to exclude a library from anyone except admistrators seeing.  *PUBLIC is exclude and the owner is GRPITIMPL.  Other users are able to get into this library and muck around.  I change the owner to OWNIT and they aren't.

What the heck is going on here!

Brian Rusch
Advanced Member
Advanced Member
Posts:549

--
31 Jan 2013 04:19 PM
Change the owner of the library back to GRPITIMPL and sign on as a user that should not have authority (create a test user if you have to) and do a DSPOBJAUT OBJ(libraryname) OBJTYPE(*LIB). If you see anything but public authority exluded, then that's where the security issue could be. It's important in the test to try to recreate the same conditions (programs called, other group profiles used) that the users have who are getting access and should not be.
davesmith
Veteran Member
Veteran Member
Posts:1241
Avatar

--
01 Feb 2013 09:14 AM
If you run the following what do you see? Just the administrators?
DSPUSRPRF USRPRF(GRPITIMPL) TYPE(*GRPMBR)

If so, do any of the users that are unwelcome, have any special authorities? If they have *ALLOBJ it obviously would allow them to bypass any object authority settings you're making.

And if still no joy, then they are probably... running some code that adopts sufficient authority (probably GRPITIMPL). You can probably find this with:
PRTADPOBJ USRPRF(GRPITIMPL)
... but read the caveats in the help text or manual before your run this command if youre not familiar with them.

Dave
Rocky Marquiss
Senior Member
Senior Member
Posts:2905

--
06 Feb 2013 01:23 PM
You probably want the user profiles owned by QSECOFR - with GRPITIMPL authority added to it along with the user id - this is the recommended approach - I'd stay clear from making GRPITIMPL the owning profile.

Then I'd create an authority list with same name as library - in it is *PUBLIC *EXCLUDE, GRPITIMPL *ALL (or whatever aut you want those in that group to have) - then on the library specify the authority list you just created, *PUBLIC - *AUTL

Have the library owned by QSECOFR as well as the AUTL

Then CHGLIB with CRTAUT(authority just created)

Lennea Kernaz
Basic Member
Basic Member
Posts:89

--
01 May 2013 10:32 AM

To update, I located the source of our strangeness.  Somewhere along the way someone changed our menu program to adopt GRPITIMPL authority.

Boy this one had me spinning my wheels for a long time.

Emmanuel
Veteran Member
Veteran Member
Posts:776
Avatar

--
06 May 2013 02:52 PM

"Boy this one had me spinning my wheels for a long time."

 Why? Dave's suggestion on February 1 to use the PRTADPOBJ command would have revealed the cause of the issue.

Cheers,

Emmanuel

Lennea Kernaz
Basic Member
Basic Member
Posts:89

--
15 May 2013 01:26 PM
Actually Emmanuel I did. It had been resolved for some time but I never updated this thread with the results so just wanted to close the loop.
You are not authorized to post a reply.

Acceptable Use Policy