[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: Removing user from "shared" status
From:       Alan Altmark <Alan_Altmark () US ! IBM ! COM>
Date:       2017-02-24 14:51:13
Message-ID: OF76A22D3F.3AE75F01-ON852580D1.004F6747-852580D1.00519829 () notes ! na ! collabserv ! com
[Download RAW message or body]

On Friday, 02/24/2017 at 08:10 GMT, Berthold Gunreben <bg@SUSE.DE> wrote:
> Just as a sidenote, if you want to have both, logonby and direct logon,
> you just have to permit the user logonby for itself in addition.

These days, this is a red flag.  Back when the dinosaurs ruled the Earth, 
we had The Boss and his or her Administrative Assistant.   The AA would 
LOGON BY to Boss' ID and do the things The Boss didn't like to to do. Then 
the 1990s happened, meteors struck, and for good or ill we moved our 
e-mail and other collaboration systems off the mainframe.  That meant that 
this secretarial relationship between two virtual machines no longer 
exists on z/VM, leading me to assert that the RACF idioms to support it 
should not be used.

Consequently a shared (aka "task") ID in 2017 does not have direct logon 
capability.  In fact, it is a protected ID (NOPASSWORD NOPHRASE).  If a 
human wants to access the virtual machine to run a program, they use LOGON 
BY.  If they just want access to the virtual machine's resources, then you 
may choose to give them direct access to those resources so that not even 
LOGON BY is required.

New World Order:
- Only IDs assigned to humans have passwords.
- All other virtual machine access is performed using LOGON BY <human>.
- Exceptions granted APIs that require authentication.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
Alan_Altmark@us.ibm.com
IBM Endicott
[prev in list] [next in list] [prev in thread] [next in thread]