Discussion:
Refresh my memory: what is it that controls the public authority . . .
(too old to reply)
CRPence
2014-10-18 18:14:08 UTC
Permalink
Raw Message
<<SNIP>> public authority when new programs and files <<SNIP>>
is there any setting (other than the obvious case of the object's
owner not existing on the target system) that can cause a change in
the public authority when an object is restored <<SNIP>>
Portions of the quoted message are snipped per having already been
/answered/; dealing with the QCRTAUT System Value (SYSVAL) and Create
Authority (CRTAUT) attribute and parameter-keyword on both Create
Library (CRTLIB) and Change Library (CHGLIB) commands.

AFaIK the *PUBLIC authority remains unchanged even for the scenario
whereby the owner of the object is unavailable [missing or damaged] on
the target system; i.e. an owner would be assigned per msg CPI371E, but
that effect should not result in any change to the public authority.

If secured by an authorization list, and that *AUTL object is missing
or otherwise unavailable, public authority defined via that Aut List
will be lost per msg CPI3721; with an associated AUTL(), but not also
defining the *PUBLIC authority per AUT(*AUTL), I believe that condition
is diagnosed by msg CPI3720.

If the user performing the restore does not have the necessary
[special] authorities [e.g. SPCAUT(*SECADM *ALLOBJ)], then as I recall,
the saved programs that were defined with USER(*OWNER) [to effect
adopted authority of the object owner], the [public] authority of the
object and\or the adoption attribute may be changed. I do not recall
the diagnostic message or the specific scenario(s) for which the issue
arises. In that case the restore of the object completes but the
overall restore request would /fail/ with an Escape message indicating
that some prior /attribute changes/ were effected during the restore.
Similar issues might arise with similar [lack of] attributes for the
user performing the restore, but for different origins of [effective]
authority changes; e.g. msg CPI3738 regarding the User ID number (UID)
and Group ID number (GID) of the owner on media and those on the system.

As I recall the above alluded effect for the adopted authority case,
is different than what the Allow Object Restore (QALWOBJRST) system
value setting would effect when the effect is limited [i.e. other than
*ALL to allow the restore of all objects irrespective any security
sensitive attributes, diagnosed by the msg CPD373F]. Clearly, because
that scenario actually prevents the restore per the first level message
text stating "&1 in library &3 with adopt authority attribute not restored".

A program-described database *FILE object that is restored with the
name of an existing [but deprecated] Authority Holder (AUTHLR) object,
the file will take the authority defined in the authority holder rather
than restoring with the [public] authority from the save.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
CRPence
2014-10-18 22:06:11 UTC
Permalink
Raw Message
<<SNIP>> If the user performing the restore does not have the
necessary [special] authorities [e.g. SPCAUT(*SECADM *ALLOBJ)], then
as I recall, the saved programs that were defined with USER(*OWNER)
[to effect adopted authority of the object owner], the [public]
authority of the object and\or the adoption attribute may be changed.
I do not recall the diagnostic message or the specific scenario(s)
for which the issue arises. In that case the restore of the object
completes but the overall restore request would /fail/ with an Escape
message indicating that some prior /attribute changes/ were effected
during the restore. <<SNIP>>
Either of the errors, msg CPF3852 or msg CPF3853, describes the above
scenario. And the error msg CPF3848 "&1 security or data format changes
occurred" describes that a prior condition of CPF3852 could be one
possible origin. The error msg CPF3773 documents that the restore had
errors.

The scenario I had alluded to above is explained by the following
message text; FWiW I originally had overlooked entirely the CP_3800
range of messages, having recalled only CP_3700 messages as belonging to
the Save\Restore (SR) feature:

CPF3852 "All authorizations to &2 &1 in library &3 revoked."
Cause: &2 &1 in library &3 adopted the user profile of the
object owner and the object was restored by a user who
was not the owner of the object and who did not have all
object authority (*ALLOBJ) and security administrator
authority (*SECADM).
Recovery: Obtain authority from the owner of the object or
obtain all object (*ALLOBJ) and security administrator
authority (*SECADM) special authority from the security
officer.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/***@public.gmane.org
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Loading...