Re: Remnants of group profiles...

Rob Berendt wrote on 03/29/2006 08:21:32 AM:

> We are moving from group profiles to authorization lists.
>
> We have several files that are stored in save files.  They are restored
> into QTEMP for processing.  It's a way of creating some empty shell
> physical files and several logical files.
>
> However, when I remove a user from the group profile and just have it in
> the authorization list assigned to that object I am getting the following

> error when they restore the data from the save files into QTEMP:
>
>  Message ID . . . . . . :   CPF3757       Severity . . . . . . . :   20

>  Message type . . . . . :   Diagnostic
>  Date sent  . . . . . . :   03/29/06      Time sent  . . . . . . :
> 08:45:23
>
>  Message . . . . :   FILE SD855D01 not restored to QTEMP.
>  Cause . . . . . :   The user profile under which the restore operation
is
>
>    running does not have *ADD authority to user profile SSA13.
>  Recovery  . . . :   Do one of the following and try the request again:

>      -- Have the security officer grant you *ADD authority to user
profile
>
>    SSA13 using the Grant Object Authority (GRTOBJAUT) command.
>      -- Sign on under a user profile which has save system (*SAVSYS)
> special
>    authority.
>  Technical description . . . . . . . . :   User profile SSA13 is either
> the
>    owner of the object or the system default owner QDFTOWN.  If the owner

> of
>    the object does not exist on the system, the system will attempt to
> transfer
>    the ownership of the object to QDFTOWN.
>
>
> 1 - What the blazes is *ADD authority?  I suspect it is some mythical
> authority made up in the IBM lab that in reality means the proper
> combination of Object authority and User authority on EDTOBJAUT
> groupprofile.  If so, then what combination is required to restore an
> object owned by someone else?

Actually *ADD authority is one of the elemental authorities that other
authorities like *CHANGE and *ALL are make from. See the first few charts
in the beginning of Appendix D of the Security Reference manual for
complete details. You can also find a description of *ADD in the help text
of the AUT parameter of GRTOBJAUT.

What the message is saying is that your users must have *ADD authority to
the user profile that owns the object being restored. When you used group
profiles this is something that each member of the group automatically had
to their group profile.

> 2 - Other workarounds include:
> 2a - Giving lots of users *SAVSYS authority.
> 2b - Dropping the save file technique and coming up with some other
> technique for creating the shells and logicals
> 2c - Adopting authority on every program that restores these shells.

I don't recommend option 2a. That would be a bad security design. At the
moment the only additional workaround I can think of would be to use
GRTOBJAUT or EDTOBJAUT to grant each user that will run these applications
*ADD authority to the user profile that owns the files. Do not give then
*USE authority because that would allow them to submit jobs and swap the
user profile of the job to the profile that owns the shells. A possible
exposure to this solution is that these users could now cause this user
profile to own programs and other objects.

In my opinion the best solution would be a variation of 2c where the
programs that restores the shells is owned by the same user profile that
owns the shells.

Ed Fishel,
edfishel@xxxxxxxxxx