Re: Adopting authority not?

[rob@xxxxxxxxx]

Yes.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




"Jim Franz" <franz400@xxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
04/04/2003 12:30 PM
Please respond to Midrange Systems Technical Discussion
 
        To:     "Midrange Systems Technical Discussion" 
<midrange-l@xxxxxxxxxxxx>
        cc: 
        Fax to: 
        Subject:        Re: Adopting authority not?


Rob - when you say "all the X's" are we talking both object and data 
rights?
jim
----- Original Message -----
From: <rob@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, April 04, 2003 8:59 AM
Subject: Re: Adopting authority not?


> Thank you.  However, if the adopting program is owned by SSA.  And SSA
> owns that file and has x's in every security checkbox, shouldn't that
> work?  Or does CLRPFM not support adopted authority?
>
> Rob Berendt
> --
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
> Benjamin Franklin
>
>
>
>
> "Jim Franz" <franz400@xxxxxxxxxxxx>
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 04/03/2003 08:35 PM
> Please respond to Midrange Systems Technical Discussion
>
>         To:     "Midrange Systems Technical Discussion"
> <midrange-l@xxxxxxxxxxxx>
>         cc:
>         Fax to:
>         Subject:        Re: Adopting authority not?
>
>
> Rob - the Info Center is pretty good about listing the security required
> for
> each command.
> This is what it says for CLRPFM (V5R2 Info Center).
>   1.. The user must have object operational, object management or alter,
> and
> delete authority for the physical file that contains the member and
> execute
> authority to the library.
> After saying such wonderful things about Info Center, the security
> requirements are missing for ADDPFM and RMVM.
>
> Somewhere (long ago) I saw a chart of commands and the security
> requirements
> for each.
> Anyone know where that is ??
>
> jim
>
> ----- Original Message -----
> From: <rob@xxxxxxxxx>
> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> Sent: Thursday, April 03, 2003 4:58 PM
> Subject: RE: Adopting authority not?
>
>
> > John,
> >
> > I really appreciate your in depth analysis.
> >
> > However, we use this user ADOPT to own programs in numerous other 
cases.
> >
> > Example
> > program GDIINTEDI/POEXTV is owned by ADOPT.  It is used to update this
> > file:
> > Object . . . . . . . :   IIML01          Owner  . . . . . . . : SSA36
> >   Library  . . . . . :     CLIDIVF       Primary group  . . . : *NONE
> > Object type  . . . . :   *FILE           ASP device . . . . . : 
*SYSBAS
> >
> > Object secured by authorization list  . . . . . . . . . . . . : *NONE
> >
> >                          Object
> > User        Group       Authority
> > SSA36                   *ALL
> > *PUBLIC                 *EXCLUDE
> >
> > Remembering that SSA36  is a supplemental group of ADOPT.
> >
> > I am doing some testing to see if CLRPFM is just pickier than other 
data
> > operations.  For example, while I can create a program which adopts
> > QSECOFR to create user profiles, that program cannot give that new 
user
> > profile a group profile that the job user does not have access to.
> > (Remember my QTCP ftp exit point issue?)  I am wondering if CLRPFM has
> > some strange requirement.  The gent who does the most here with 
adopting
> > was pretty sure that he does RMVM, and ADDPFM with adopted authority,
> but
> > he didn't look like he  was willing to bet the farm on it.
> >
> > Rob Berendt
> > --
> > "They that can give up essential liberty to obtain a little temporary
> > safety deserve neither liberty nor safety."
> > Benjamin Franklin
> >
> >
> >
> >
> > "John Earl" <john.earl@xxxxxxxxxxxxxxxxxx>
> > Sent by: midrange-l-bounces@xxxxxxxxxxxx
> > 04/03/2003 04:05 PM
> > Please respond to Midrange Systems Technical Discussion
> >
> >         To:     "'Midrange Systems Technical Discussion'"
> > <midrange-l@xxxxxxxxxxxx>
> >         cc:
> >         Fax to:
> >         Subject:        RE: Adopting authority not?
> >
> >
> > Rob,
> >
> >
> >
> > When I read this I see.
> >
> >
> >
> > *         *PUBLIC has at least *USE authority to library EDI.GDI, so
> there
> > is adequate authority to work with the existing objects in the library
> >
> > *         User "SSA" owns, and has all authority to file
> EDI.GDI/HMDEMH01,
> > which is sufficient authority to " clear, initialize, or copy member".
> >
> > *         *PUBLIC has *CHANGE authority to the file EDI.GDI/HMDEMH01,
> > which
> > is insufficient authority to " clear, initialize, or copy member".
> >
> > *         User "ADOPT" owns the program EDI.PGM/HMDEMC01 which 
attempts
> to
> > clear or copy.
> >
> > *         User Profile "ADOPT" belongs to the group "SSA", but adopted
> > authority cannot come from the group profile of a program's owner.
> >
> > *         Program EDI.PGM/HMDEMC01 runs with the authority of the
> calling
> > user plus the authority of "ADOPT", but not with the authority of
> > "ADOPT"'s
> > group ("SSA"), therefore the operation fails.
> >
> >
> >
> > >From my limited view of this, it appears that you have to either give
> > ADOPT
> > *OBJMGT rights to the file (which seems reasonable) or have the 
program
> > adopt SSA's authority (which seems excessive).  In any case there does
> not
> > seem to be real value in having ADOPT a member of the SSA group.
> >
> >
> >
> > jte
> >
> >
> >
> > --
> >
> > John Earl | Chief Technology Officer
> >
> > The PowerTech Group
> >
> > 19426 68th Ave. S
> >
> > Seattle, WA 98032
> >
> > (253) 872-7788 ext. 302
> >
> > john.earl@xxxxxxxxxxxxxxxxxx
> >
> > www.powertech.com
> >
> >
> >
> >
> >
> > --
> >
> > _______________________________________________
> > 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.
> >
> >
> > _______________________________________________
> > 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.
> >
> >
>
>
> _______________________________________________
> 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.
>
>
> _______________________________________________
> 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.
>
>


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