Re: how to GRTOBJAUT when a new file is created in a lib

On 31-Dec-2013 10:17 -0800, Mark S Waterbury wrote:

On 12/31/2013 11:29 AM, Stone, Joel wrote:

Sally creates a file FILE1 in TESTLIB and forgets to GRTOBJAUT.

What is a simple method of having os400 do a default GRTOBJAUT for
any obj created in TESTLIB?

<<SNIP>> then specify that <ed: *AUTL> name as the value for the
CRTAUT parameter on the CHGLIB command. That way, whenever a new
object is created in that library, it will be automatically assigned
to that authorization list.
<<SNIP>>

Note that this method (changing the CRTAUT attribute via CHGLIB)
will not automatically take care of objects that get "restored" into
that library. So you may still need additional tools, such as a good
change management tool or product, to assist with that.

Just like with /restore/, there are other features for which either no capability exists to specify the AUT(), or for which AUT(*LIBCRTAUT) specification is not the default or requested behavior, for which the Creation Authority (CRTAUT) of the Library object is ineffective to implicitly establish the authority to the object created in that library. Thus, beyond just restore, there are other instances for which not always "whenever a new object is created in that library." At least each of CRTDUPOBJ and CPYF CRTFILE(*YES) had been; I tried to get the latter to add an AUT() parameter to avoid its requirement to mimic CRTDUPOBJ copying the authority of the original [because irrespective of the design intention to imply as-secured, its goal is both nonsensical and problematic especially given the FROMFILE can be an LF but the created file is always a PF]. The restore can even restore saved private authorities with the PVTAUT().

Like has been suggested already, forcing "Sally" to use an interface that ensures the proper authorities are established, is a good approach for structured [i.e. not ad-hoc] creations. For ad-hoc create activity, the best bet may be to perform reactive corrective action; e.g. batched overnight or quicker, as effected by [like HA] monitoring the audit journal and scheduling the grant\revoke authority activity... being aware that performing the authorization requests may not be able to be implemented due to locks held by the creator, so being able to reschedule the authority modifications is important. And like HA providers learned, they can not be too aggressive at *immed scheduled actions in response to a T-CO create-object audit entry, because serial activities in the job that had just created the object may depend on being able to immediately obtain another lock to perform the next step in their processing; i.e. such that asynchronous GRTOBJAUT or similar work might cause the creator of the object to fail to access the object in its next request.