Like I said, I have never witnessed such a situation. Your case is hypothetical, and I admit there may be other hypothetical cases where it is necessary to enroll all but a few users in a filepool and then using the grant public mechanism without public being enrolled. What happens if one of those who is denied access need to see other files in the filepool? It is better to not authorize public if you want to deny access to anyone.
Without having a Deny Access capability in SFS, there probably is no really good answer to the various cases that can be conjured. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams > Sent: Thursday, June 19, 2008 8:44 AM > To: [email protected] > Subject: Re: SFS REVOKE AUTH question > > On Thu, 19 Jun 2008 08:32:59 -0700 Schuh, Richard said: > > > >> > >> One minor correction, PUBLIC grants access to everyone who > has been > >> enrolled in the filepool. If the id in question is not > enrolled, it > >> gains no access. They'll receive a DMSACCR1240E if they try to > >> ACCESS the directory, FPLSFS733E reason code 30100 if they try to > >> read a file with PIPEs, etc. > >> Not helpful if it is the filepool where all users connect, but > >> useful in some situations. > >Not so if PUBLIC has been enrolled. > >"Purpose > > > >Use the ENROLL PUBLIC command to give connect authority for > a file pool > >to all users. File pool administration authority is required to use > >this command." > >I have never been in a situation where I did not want users > to not see > >Public data. It may be possible that there are circumstances > where it > >is necessary to keep only one or a few users away from data that is > >accessible to everyone else. I just have not encountered > any. If that > >is the case, do not enroll public and only enroll those users who do > >need access. In many cases, that means thousands of > enrollments. That > >could be cumbersome and even become unworkable if someone who is > >legitimately enrolled and has data in the pool suddenly gets > put on the > >blacklist. I find it much easier to enroll Public and not > put sensitive > >data in any directory that has authorized everyone. > > The use case that comes to mind is that you have a filespace > that you want to restrict access to a large group of people, > but not everyone and you don't want to have a large number of > authorization records in the catalog. Without an ESM, every > grant is an entry in the catalog, which increases its size, > and slows down the process to check authorizations. > > I'm not saying it's a good case, but it is s case. > > I had forgotted about enrolling PUBLIC. It isn't something > we do, and at one time was on the "not reccomended" list. > We've moved a couple things to separate filepools to ease > access control. > > > > > >Richard Schuh > > > /ahw >
