On Wed, 18 Jun 2008 08:52:50 -0700 Schuh, Richard said: >Unfortunately for you, granting authority to PUBLIC grants it to >everyone who has an id on the system. If the filepool is listed as a
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. >Global Resource, the authority carries over to other systems connected >to your system via APPC. Yes, PUBLIC is the problem. And via ISFC >Your ESM may provide an out. I do not know the abilities of VM:Secure >and RACF in this area. SafeSFS may be another way to control access the >way you are hoping for. Whenever I enroll a new user in our SFS, I tell >them to not grant authority to PUBLIC for any files or subdirectories >that they would not want posted on the web or printed in the Enquirer. >Regards, >Richard Schuh /ahw > >> -----Original Message----- >> From: The IBM z/VM Operating System >> [mailto:[EMAIL PROTECTED] On Behalf Of Gentry, Stephen >> Sent: Wednesday, June 18, 2008 8:23 AM >> To: IBMVM@LISTSERV.UARK.EDU >> Subject: SFS REVOKE AUTH question >> >> I am trying to REVOKE AUTH for an SFS user. The directory, let's call >> it VMSYS:MAINT.PUBLIC has had a GRANT AUTH PUBLIC done to >> it earlier. >> I have a specific user I do not want to access this >> directory. When I issue the REVOKE AUTH, (specifically: >> revoke auth vmsys:maint.public from steveg) I get >> DMSJAU1138E File sharing conflict with a return code of 70. >> The user is not logged on when I issue the command. >> Is the PUBLIC authority causing this problem? >> Thanks, >> Steve >>
