RE: Adopted authority vs profile switching

["John Earl" <john.earl@xxxxxxxxxxxxx>]

Pardon my ignorance, but what is DCR?

jte

--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of the 
intended recipients and may contain information that is privileged and 
confidential. If you are not the intended recipient, any dissemination, 
distribution, or copying is strictly prohibited. If you received this email 
message in error, please immediately notify the sender by replying to this 
email message, or by telephone, and delete the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Tuesday, July 20, 2004 2:44 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: Adopted authority vs profile switching
> 
> 
> 
> Maybe it's time to just try the DCR and see if I get shot
> down it flames?
> 
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> |-----------------------------+---------------------------
> ----------------|
> |   "John Earl"               |
> |
> |   <john.earl@xxxxxxxxxxxxx> |
> |
> |   Sent by:                  |
> To|
> |   midrange-l-bounces@midrang|
> "Midran|
> |   e.com                     |
> ge     |
> |                             |
> Systems|
> |   07/20/2004 03:27 PM       |
> Technic|
> |                             |
> al     |
> |         Please respond to   |
> Discuss|
> |         Midrange Systems    |
> ion"   |
> |       Technical Discussion  |
> <midran|
> |      <midrange-l@xxxxxxxxxxx|
> ge-l@mi|
> |                m>           |
> drange.|
> |                             |
> com>   |
> |                             |
> cc|
> |                             |
> |
> |                             |
> Subject|
> |                             |
> RE:    |
> |                             |
> Adopted|
> |                             |
> authori|
> |                             |
> ty vs  |
> |                             |
> profile|
> |                             |
> switchi|
> |                             |
> ng     |
> |                             |
> |
> |                             |
> |
> |                             |
> |
> |                             |
> |
> |                             |
> |
> |                             |
> |
> |-----------------------------+---------------------------
> ----------------|
> 
> 
> 
> 
> 
> 
> Rob,
> 
> > But they've already introduced that security exposure by
> > supporting
> > profile switching.  So why not just have adopted
> authority
> > work in the
> > first place?
> 
> Again,  I don't see profile swapping as a security
> exposure all by
> itself, but maybe we can just agree to disagree on this
> point as it's
> not central to either of our arguments.
> 
> 
> > I understand what you are saying about changes breaking
> > other code.  But I
> > don't find that applicable in this case.  I can already
> > create a program
> > that does a CALL QCMD, owned by QSECOFR and any user can
> > run it and then
> > execute the following command:
> > CRTUSRPRF USRPRF(DELME) USRCLS(*SECOFR)
> > But they can't run this command:
> > CRTUSRPRF USRPRF(DELME2) USRCLS(*SECOFR) GRPPRF(SSA)
> > OWNER(*GRPPRF)
> > CPF9802-Not authorized to object SSA in QSYS.
> > But then user DELME can sign on and do CHGUSRPRF DELME
> > GRPPRF(SSA)
> > OWNER(*GRPPRF)
> 
> The argument against breaking code goes something like
> this...
> 
> If I wrote an adopted authority program that does not
> allow my users to
> have access to Group profiles (and in fact I'm counting on
> this
> behavior), and then IBM changes the basic behavior to
> "fix" this aspect
> of adopted authority so that users now have this ability,
> a potential
> security exposure is introduced.
> 
> I don't like this argument, in fact I can cite at least
> two current
> examples where some section of IBM code doesn't subscribe
> to their
> S.O.P, but because it's been that way for a couple of
> releases the
> developers are fighting making changes.  I have pretty
> compelling
> arguments, but that status quo seems to be stronger than
> operational
> consistency :(
> 
> jte
> 
> 
> --
> John Earl | Chief Technology Officer
> The PowerTech Group
> 19426 68th Ave. S
> Seattle, WA 98032
> (253) 872-7788 ext. 302
> john.earl@xxxxxxxxxxxxx
> 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.