If you want to try to 'roll your own' SFS authorisation package, look at 'WORF' on the VM download page.
Peter -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: June 19, 2008 12:52 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question 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: IBMVM@LISTSERV.UARK.EDU > 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 > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
