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.
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.