Most of our major 3rd party apps use their own application security to control who does what etc.
What we don't what and used to have is a batch process failing because of lack of authority.
Thus the reason to fix/standardize.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Monday, August 15, 2016 2:32 PM
To: Midrange Systems Technical Discussion
Subject: RE: Force or change the object owner on an object restore
You know, with you setting up *PUBLIC with authority to everything on your system, including "production" libraries and whatnot, it makes me wonder why you just don't run at QSECURITY=20. Not that I am really advocating that, but, with your setup, what's the difference?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>
Date: 08/15/2016 01:52 PM
Subject: RE: Force or change the object owner on an object restore
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Chuck,
Thanks for the options.
I'm doing something similar now in batch.
All objects get restored to a temp install library.
I then run a CL with the below commands (i5/OS and TAATOOL) on the temp
library.
I also use the same CL to fix/standardize authorities on main production
libraries.
CHGLIBOWN LIB(&LIBNAM) NEWOWN(CM_GRP) OLDOWN(*ANY) +
CUROLDOWN(*REVOKE) OMITOWN(*NONE) /* +
Change ownership of the library */
CHGOBJAUT OBJ(QSYS/&LIBNAM) OBJTYPE(*LIB) USER(*ALL) +
AUT(*REMOVE) DLTSPLF(*NO) /* Remove +
LIBRARY private authority */
CHGOBJAUT OBJ(QSYS/&LIBNAM) OBJTYPE(*LIB) USER(*PUBLIC) +
AUT(*CHANGE) DLTSPLF(*NO) /* Grant +
*change authority to the LIBRARY *PUBLIC +
user */
CHGOBJAUT OBJ(&LIBNAM/*ALL) OBJTYPE(*ALL) USER(*ALL) +
AUT(*REMOVE) DLTSPLF(*NO) /* Remove +
private authorities for all objects in +
the library */
CHGOBJAUT OBJ(&LIBNAM/*ALL) OBJTYPE(*ALL) USER(*PUBLIC) +
AUT(*CHANGE) DLTSPLF(*NO) /* Grant +
*CHANGE authority for user *PUBLIC to all +
object in the library. */
DSPLIBAUT LIB(&LIBNAM) BYPOWNER(*YES) OUTPUT(*PRINT)
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Monday, August 15, 2016 12:50 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Force or change the object owner on an object restore
On 15-Aug-2016 10:58 -0500, Steinmetz, Paul wrote:
I would like to force or change the object owner on an object restore.
Ideally the owner would be the desired value when saved. Restore will
assign the same owner as was recorded on the media, or to the /default/
owner (QDFTOWN) when the same-named User Profile (USRPRF) does not exist
at the restored-to system.
Is there a simple way to achieve this?
Yes, relatively simple, esp. for /QSYS.LIB objects. But as reactive vs
proactive, and thus if there would be repeated restores, /expensive/ in
terms of system resources if effected after each restore on the
restored-to system, as contrasted with effecting the changes just once on
the saved-from system completed prior to the save.
The Output (OUTPUT) feature of the restore functions could be used to
provide the list of objects for which ownership should be changed; any
number of means can be utilized to process such a list from which to
build\perform the required Change Object Owner (CHGOBJOWN) [or CHGOWN]
requests; e.g. RCVF in a CLP, a SQL query, etc. -- noting that for
non-/QSYS.LIB objects, the likely stream file as output would need to be
copied to a PF for native RLA reads. Rather than /batching/ the changes,
with use of a pre-created Output File (OUTFILE) from the model file
QASRRSTO with record format QSRRST and specification of Add Records
(*ADD) for the Output Member Options (OUTMBR) parameter, the effect can be
achieved more directly by making the records available to a Trigger that
had been added to the file for the upcoming *AFTER *INSERT activity
-- though not likely much value to do so.
Many objects come shipped with owner of QPGMR, and that is not our
desired owner.
As worded, the issue seems possibly to be for restore of ¿3rd party?
/products/? If so, then might be worth asking why they do not have an
/application/ user [that maybe needs to be created as a pre-requisite to
installing their product]; while use of QPGMR might seem fine from their
perspective, they should realize that QPGMR will not be the same to every
installation, so they should avoid that imposition. I kinda expected that
IBM emphasized that 3rd party app providers should use their own profile
to avoid such issues.? Anyhow, if they do\will not provide for
application user(s), having created and saved with owner QPGMR [and ??],
then perhaps asking that they provide a script [with variable\parameter
input capability] or command that allows assigning the desired alternative
to the user profile QPGMR [and ??]; that way the customer\recipient of the
media need not try to figure out, and possibly muck-up something, what to
change [and what can be safely changed, and to what user, according to
some required minimum Special Authority
(SPCAUT) or other requirements].
FWiW: If the objects are specific to a library or two, there are likely
to be command+programs already [I have probably posted one way back in the
day], that achieves what is desired; e.g. variants of CHGOWNLIB or
CHGLIBOWN tools have long existed to change ownership [of both the library
object] and all objects within the named library, to a named user profile
[possibly coded to omit redundant requests for any objects already owned
by the user named to become the new owner].
--
Regards, Chuck
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
midrange.com
