I agree. Let the ESM do it. That deny rule does exactly what is needed for the situation being discussed.
Besides, we don't want to mess with SFS code because the application of Sevareid's Law could be disastrous :-) Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Friday, June 20, 2008 9:34 AM > To: [email protected] > Subject: Re: SFS REVOKE AUTH question > > On Friday, 06/20/2008 at 12:12 EDT, "Schuh, Richard" <[EMAIL PROTECTED]> > wrote: > > > That is one possibility - separate the filepools. What if it is > > desired that a user have access to most PUBLIC data in a > filepool but > > be kept from accessing only a small fraction of it? You > have to either > > keep the user from accessing any public data, which cannot be done > > given the stated condition, or you have to move the now > sensitive data > > to a non-public location. Moving the sensitive data will cause all > > other users to change the way that they access the data. > This is where > > a Deny Access capability would be handy. > > > > Do not assume that I am asking for the capability, I am > not. We have > > not encountered a situation where it is necessary. We > protect access > > to sensitive data by requiring specific grants of > authority; no PUBLIC > > grants are given unless the data is not sensitive and is > needed by a > > large subset of our users. If we need to keep a user from accessing > > protected data, we revoke the authorities granted, or we delete the > > userid from both the filepool and the system. > > If such an SFS requirement *were* to surface, we'd probably > respond "Reject" anyway, since the interfaces are there and > the ESMs can do this. > RACF, for example, allows you to create FILE profiles of the > form "* * dirid" so that you can protect all the files in a > single directory with a single profile. You can grant > authorization to groups instead of users, so that as a > person's job responsiblities change their authorizations > change automatically as you change their group membership. > > Finally, you can define the profile in a way that gives all > users read or write access by default, and then you override > that with a "deny" rule for individuals or groups. > > Alan Altmark > z/VM Development > IBM Endicott >
