Without it being a formal policy, we have been doing that for years. Is there any significance to the POSIXINFO statement in a NOLOG user's directory?
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark > Sent: Wednesday, July 21, 2010 3:35 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: TCP/IP Server > > On Wednesday, 07/21/2010 at 06:06 EDT, "Schuh, Richard" > <rsc...@visa.com> > wrote: > > Keeping those ids in place does nothing to protect the file space if > your > > statement, "A user with the same name as an SFS filespace > (whether it > > is > BFS or > > not) has ownership rights of the filespace," is true. There > is nothing > that > > says that the name of the filespace is the same as the userid of the > file > > server. This is demonstrated quite nicely by VMSERVS being > the server > for the > > VMSYS pool. If you are trying to protect the file pool > names, then you > need to > > create ids with matching names. > > > > You have just given me one more set of names that I need to > protect in > my > > directory creation process. > > Terminology: "filespaces" are created in a "filepool" by > ENROLL USER. The name of the filepool isn't important and no > authorization is conferred if your user ID matches the name > of a filepool. > > It is possible to prevent this, but you wouldn't want to try. > You would have to remove the IUCV ALLOW statement from the > filepool server's directory entry and add IUCV <filepool> > statements to all users. Bleh. > It's easier to simply have a policy that any id enrolled in a > filepool MUST have a VM user ID created for it, even if it is NOLOG. > > With an ESM on the system, you can have a user defined as > NOLOG in the directory, yet enrolled in the ESM with a valid > password. Such a configuration enables you to authenticate > (e.g. via FTP) and have remote access to resources, but you > can't actually log on. > > Alan Altmark > z/VM Development > IBM Endicott >
