The cases under discussion were hypothetical. I have never needed nor have I seen a real case that could not be handled with the current facilities. Considering my employment situation, a home-grown solution would not be viable if the capabilities of WORF & WORFAUTH are needed. It would have to be included in CMS or be an integral part of an overall ESM from a short list of vendors. Should the situation arise, I would be more inclined to write a requirement requesting the capability if it is not already in one of the ESMs. I am not too worried about it because I do not think that it will be needed before I retire.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, June 19, 2008 9:56 AM > To: [email protected] > Subject: Re: SFS REVOKE AUTH question > > 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: [email protected] > 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: [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 > > > > > 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. >
