|
Rob, >I think I have a workaround. >GRTOBJAUT OBJ(EDIONR) OBJTYPE(*USRPRF) USER(thisuser) AUT(*OBJOPR *ADD) Check the "Commands Common for Most Objects" table in Appendix D of the Security Reference manual and you will see that you only need to give the user *ADD authority to a user profile to allow then to restore objects that will be owned by that user profile. >Any potential security breaches with this solution? There are things to consider. The user can now use CHGOBJOWN, CHGOBJPGP, RSTOBJ, and CRTxxx with REPLACE(*YES) to cause objects to be owned by the user profile to which they have *ADD authority. This could be used to cause problems for someone else if their user profile has a maximum storage allowed limit. It could also be used to avoid someone's own limit by causing their objects to be owned by someone else. Letting someone change the primary group of an object could also mess up your security design. By itself, this should not be a problem for programs that adopt their owners authority. See the "Objects That Adopt the Owner's Authority" section of Chapter 5 of the Security Reference Manual for more information. Ed Fishel, edfishel@xxxxxxxxxx
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.