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
