I don't believe that I said DELETE USER RICHARD. I certainly did not intend to imply that, nor did I intend for someone to infer it. I should have stated it better.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[email protected]] On Behalf Of Les Koehler > Sent: Tuesday, March 01, 2011 2:07 PM > To: [email protected] > Subject: Re: CMS SFS Question > > That's NOT the scenario you gave in your original note! You > wrote about deleting Richard when you wrote: > > It is possible for one user to grant access to other users > >>>> who are not enrolled. DELETE USER does not clean up > these >>>> permissions. > > I don't see *any* indication that would trigger a DELETE USER > Les (using your scenario, which was reversed from mine, > further confusing the issue). > > Les > > Schuh, Richard wrote: > > It is permissions granted to users who are not enrolled > that is the issue. Here is the scenario: > > > > User Richard is enrolled > > User Les is not enrolled > > Richard grants Les some SFS authorities. > > DELETE USER LES is issued without enrolling LES (or no > DELETE USER is > > issued for LES) The authorities granted to LES by RICHARD > are left hanging and will be applied to any newly created LES > regardless of the identity of the owner. > > > > If LES is enrolled before the DELETE USER, those > authorities granted to LES by others are removed. By doing > the ENROLL for 0 blocks for any userid that is to be deleted, > no ghost authorities are given to new users. The userids are > unconditionally enrolled. If the user has already been > enrolled and owns a file space, the enroll will fail. Because > all I care about is that the user be enrolled, I ignore that failure. > > > > > > Regards, > > Richard Schuh > > > > > > > >> -----Original Message----- > >> From: The IBM z/VM Operating System > >> [mailto:[email protected]] On Behalf Of Les Koehler > >> Sent: Tuesday, March 01, 2011 1:24 PM > >> To: [email protected] > >> Subject: Re: CMS SFS Question > >> > >> I guess there's something implied there that I don't get. > >> Scenario, from your note: > >> > >> Your task is to delete LES, who is enrolled, from the SFS > system LES > >> has granted rights to RICHARD but RICHARD is not enrolled > >> > >> How does enrolling LES for 0 blocks do anything about the granted > >> rights that RICHARD has? > >> > >> Les > >> > >> Schuh, Richard wrote: > >>> I simply enroll any user to be deleted for 0 blocks. The > >> alternative is to scan the sfs directories and files > looking for such > >> users. It is much easier to attempt the enroll. If it fails, it is > >> because the user is already enrolled. > >>> Regards, > >>> Richard Schuh > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: The IBM z/VM Operating System > >>>> [mailto:[email protected]] On Behalf Of Les Koehler > >>>> Sent: Tuesday, March 01, 2011 12:22 PM > >>>> To: [email protected] > >>>> Subject: Re: CMS SFS Question > >>>> > >>>> I'm curious: How do you find the user who is not enrolled, but > >>>> granted rights to the target user to be deleted? > >>>> > >>>> Les > >>>> > >>>> Schuh, Richard wrote: > >>>>> The Pipe is the easiest. > >>>>> > >>>>> PIPE < user list | spec /delete user/ 1 w1 nw | cms | > > >> delete log a > >>>>> Note, however, that if you have an SFS that has a lot of > >>>> files and permissions, each DELETE USER can take a long > >> time, so you > >>>> do not want to do this on an id that you might need soon > after you > >>>> enter the PIPE command. In our shop, an individual > DELETE USER can > >>>> take upwards of 10 minutes. > >>>>> Cleaning up SFS when a userid is deleted is important from > >>>> a security standpoint. If the same id should be given to a > >> different > >>>> person, it would automatically inherit permissions from > the prior > >>>> owner. You should be doing a DELETE USER every time that a > >> userid is > >>>> deleted from the directory. > >>>>> It is possible for one user to grant access to other users > >>>> who are not enrolled. DELETE USER does not clean up these > >>>> permissions. To get rid of them, you have to first enroll > >> the user in > >>>> the pool even if it is for 0 blocks. To solve this in our > >> automated > >>>> process, each user to be deleted is enrolled for 0 blocks, > >> ignoring > >>>> the return code. We don't care if the user is already > >> enrolled, the > >>>> attempt does no harm. After the enroll, the deletion will > >> clean out > >>>> all permissions granted to or by the user being deleted. > >>>>> Regards, > >>>>> Richard Schuh > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: The IBM z/VM Operating System > >>>>>> [mailto:[email protected]] On Behalf Of Rick Troth > >>>>>> Sent: Tuesday, March 01, 2011 10:54 AM > >>>>>> To: [email protected] > >>>>>> Subject: Re: CMS SFS Question > >>>>>> > >>>>>> Nahh ... even easier ... Pipes. > >>>>>> I'm thinking two pipes. One to gather the Q ENROLL > >> output then a > >>>>>> second to actually perform the deletes. In between > shove that Q > >>>>>> ENROLL output into a file, manually edit for confirmation, > >>>> then feed > >>>>>> the selected content into DELETE USER. > >>>>>> > >>>>>> -- R; > >>>>>> Rick Troth > >>>>>> Velocity Software > >>>>>> http://www.velocitysoftware.com/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, 1 Mar 2011, Rich Smrcina wrote: > >>>>>> > >>>>>>> REXX? > >>>>>>> > >>>>>>> On 03/01/2011 12:35 PM, Wandschneider, Scott wrote: > >>>>>>>> Is there a way to delete multiple users at once or create > >>>>>> a "batch" job to delete multiple users that are > enrolled in SFS? > >>>>>>>> Thank you, > >>>>>>>> Scott R Wandschneider > >>>>>>>> Systems Programmer 3|| Infocrossing, a Wipro Company > || 11707 > >>>>>>>> Miracle Hills Drive, Omaha, NE, 68154-4457|| ': > 402.963.8905 || > >>>>>>>> Ë:847.849.7223 || : > >>>>>> [email protected] **Think > >>>>>>>> Green - Please print responsibly** > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Confidentiality Note: This e-mail, including any > >>>>>> attachment to it, may contain material that is confidential, > >>>>>> proprietary, privileged and/or "Protected Health > >>>> Information," within > >>>>>> the meaning of the regulations under the Health Insurance > >>>>>> Portability& Accountability Act as amended. > >>>>>> If it is not clear that you are the intended > recipient, you are > >>>>>> hereby notified that you have received this transmittal in > >>>> error, and > >>>>>> any review, dissemination, distribution or copying of > >> this e-mail, > >>>>>> including any attachment to it, is strictly prohibited. If > >>>> you have > >>>>>> received this e-mail in error, please immediately return > >> it to the > >>>>>> sender and delete it from your system. Thank you. > >>>>>>> -- > >>>>>>> Rich Smrcina > >>>>>>> Velocity Software, Inc. > >>>>>>> http://www.velocitysoftware.com > >>>>>>> > >>>>>>> Catch the WAVV! http://www.wavv.org WAVV 2011 - April > >> 15-19, 2011 > >>>>>>> Colorado Springs, CO > >>>>>>> > >>>>>>> >
