QSECADM creates and deletes user profiles in our shop. Does not have the authority to delete objects owned by these profiles QSECADM is trying to delete. I initially created a CL that runs under QSECOFR authority and does wrkobjown against the profile. This gives QSECADM the bility to delete, change owner etc on these objects, but it also has command line capabilities which I don’t want to allow .

Another thought would be to change ownership of these objects to a temp user profile, then allow QSECADM access to these objects.

Any other ideas ?

Thanks,
Bill

Since you asked for ideas… you could build your own streamlined version of wrkobjown. The List Objects User is Authorized to, Owns, or is Primary Group of API QSYLOBJA can be used to get a list of objects the user is authorized to. With parameter 5, Returned objects, you can request that only the objects owned be returned. You would need to call the API twice (once for library based objects, once for IFS based objects) and then, most likely, build a subfile and enable whatever actions/operations you wanted QSECADM to be able to do. Obviously a command line would not be part of your application lol

Bruce Vining
http://www.brucevining.com/
Integrated solutions for the System i user community

What I have ended up doing is writing 2 CLP’s. The first does some verification ie; verifying the user running this CL is QSECADM, verifying the profile name passed to be worked with is actually a user profile etc. Then I call a 2nd CL that does DSPUSRPRF of the requested profile to an outfile, Read from the outfile and GRTOBJAUT to the objects to QSECADM. Then return to the 1st CL and use WRKOBJOWN to allow QSECADM the ability to delete, change ownership etc of the owned objects.

The 1 st CL runs under *USER Authority, The 2nd CL runs under QSECOFR authority.

This way even though QSECADM has command line on the WRKOBJOWN display, they are running under their own authority.

Thanks for your assistance,
Bill

QSECADM creates and deletes user profiles in our shop.

Note that having a profile of that name is potentially a bad idea. The initial letter ‘Q’ should be avoided. Such a name should be expected only to be created by IBM, and, as such, should be expected to be changed by IBM at any time.

It probably will never happen, but the habit should be enforced.

Tom