RE: Object authority

[CWilt@xxxxxxxxxxxx]

Mike,

I don't disagree with anything you've said.  As Rob mentioned, your original
(ok second) post read as if you don't use, nor recommend using the owned
program model.

I think you, Rob and I are on the same page.  Having QPGMR as the owner of
non-IBM objects, particular when using adopted authority, is a bad idea.

Charles


> -----Original Message-----
> From: Rooney, Michael P [mailto:michael.p.rooney@xxxxxxxxxxxxx]
> Sent: Tuesday, March 23, 2004 4:12 PM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: Object authority
> 
> 
> Charles,
> 
> We're getting off the RPG topic but....
> 
> In Geralds post, he indicated that all CRT commands had
> been modified so that all programs were created with
> *OWNER and that owner was QPGMR.  This assumes that the
> person executing the CRT... command is a member of or
> has authority to the QPGMR Id.  If I'm not mistaken, this
> essentially enables them to modify, change or delete 
> any/all of the programs.
> 
> Additionally, what are the *PUBLIC permissions on all
> the objects created?  If it is anything but *EXCLUDE, more
> than QPGMR has access to all the programs and files.  Hence,
> my point about having to "revoke" permissions. This also
> implies the need to "revoke" QPGMR permissions to iSeries
> commands such as CHGRPYLE or CHGJRN.    
> 
> As I stated in a subsequent post, iSeries security is a
> complex topic (probably suited for a different list) and
> solutions for 1 environment may not be best suited for
> another.
> 
> That said, I would still have an issue with creating all
> objects to execute under the QPGMR profile, as access for
> QPGMR isn't restricted to just "programming".
> 
> Michael             
> 
> 
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of CWilt@xxxxxxxxxxxx
> Sent: Tuesday, March 23, 2004 2:04 PM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: RE: Object authority
> 
> 
> Michael,
> 
> I don't see why adopted authority would require "revoking" permissions
> verses "granting " with group profiles.
> 
> Whereas many sites using adopted authority use only a single 
> owning profile.
> There's no reason why in your situation, multiple profiles 
> couldn't be used
> for different parts of the application.
> 
> Adopted authority works quite well in an environment were 
> access must be
> explicitly granted.
> 
> IMHO, it works even better than group profiles because as Rob 
> pointed out,
> with group profiles by themselves, you've given users authority to do
> whatever they want to objects and programs.
> 
> Using adopted authority, the users are simply authorized to 
> use pre-approved
> programs.  Those programs in turn have the authority to make 
> changes to the
> data.
> 
> Charles
> 
> 
> > -----Original Message-----
> > From: Rooney, Michael P [mailto:michael.p.rooney@xxxxxxxxxxxxx]
> > Sent: Tuesday, March 23, 2004 1:32 PM
> > To: RPG programming on the AS400 / iSeries
> > Subject: RE: Object authority
> > 
> > 
> > 
> > While I have no doubt that this approach works in yours (and 
> > probably other)
> > environments, the gaping hole you speak of may lay in some 
> > "unauthorized"
> > persons ability to execute one of these programs.  As the 
> > program executes
> > as *OWNER, OS/400, as you pointed out, doesn't enforce any 
> authorities
> > on the objects used by the individual executing the 
> program.  In this
> > case, it's not the "inclusion" of users that would concern 
> me but the
> > "exclusion" of individuals.  
> > 
> > What I find more concerning is the use of QPGMR.  As this is 
> > an IBM-supplied
> > profile, creating all programs to adopt these permissions is 
> > more dangerous
> > than your approach (i.e. creating a specific profile).
> > 
> > Working in a highly regulated industry, we are subjected to 
> > annual audits
> > by the FRB and SEC.  One of the items that is reviewed 
> > without hesitation
> > is the identification of programs that execute under adopted 
> > authority.  This
> > review is NOT limited to just QSECOFR.
> > 
> > Our solution is the use of Group Profiles.  Where as, we 
> > create programs and
> > files with specific ownerships based upon the application.  
> > Individual users
> > are than "added" to the group "owning" the objects.  This 
> > enables us to have
> > users enrolled in 1 group, 2 groups or no groups (i.e. exclusion).
> > 
> > Now before anyone says you can do the same by "revoking" 
> > permissions to the
> > qualified objects, we prefer to operate on the "need to use 
> > basis", where
> > you are granted access based on your need to use.  In other 
> > words, we don't
> > want to have to "revoke" access to everything we create.  
> > With 300+ users,
> > this approach works best in our environment while (most 
> > importantly) satisfying
> > regulators.
> > 
> > Hope this feedback is helpful.
> > 
> > MichaelR
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) 
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> 
> 
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) 
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>