Late to the party (I must have been in the other room that David was 
searching for), but adding on to Colin's reply below:

> "I certainly do not want a user to be able to FORCE another simply 
because they have LOGONBY authority"

We wrote a mod to CP to prevent users with PRIVCLAS 'N' from completing 
LOGOFF as expected, the CP mod changes the LOGOFF to DISCONNECT.  VTAM, 
GCS, and select other svms have been assigned class 'N' here (after 
experiencing accidental and undesirable LOGOFF of those svms by errant 
sysprogs of many backgrounds).

I empathize with Alan's original intention: making it easier to manage 
userids that you have access to logon anyway.   But as the short guy with 
the big ears (no not Mickey Mouse or George W Bush;  Ross Perot) once 
said: "The devil's in the details".

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.



"Colin Allinson" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" <[email protected]>
08/27/2007 11:54 AM
Please respond to
"The IBM z/VM Operating System" <[email protected]>



To
[email protected]
cc

Subject
Re: Ops privs







Alan Altmark <[EMAIL PROTECTED]> wrote(in part) :- 
>> I proposed that TESTABC could, for example:
>> - XAUTOLOG TCPMAINT because the user could just bring up another 
terminal 
>>   session and LOGON TCPMAINT/DISC
>> - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF
>> - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER 
>>   TESTABC/DISC or just LOGON TCPMAINT and start issuing commands
>> - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL 

>>   SHUTDOWN/DISC 
I certainly do not want a user to be able to FORCE another simply because 
they have LOGONBY authority for that userid. If allowing this is optional 
(for those shops that want it) then fine but I do not want to be put in a 
position where this is the default authority for LOGONBY. 






 
The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient 
is strictly prohibited.


Reply via email to