|
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. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.