To perform a system function, the user requires READ access to the corresponding IBMFAC:
Allows a user to change the scheduling priority of a process, process group, or user.
Allows a user to set the scheduling priority of a process, process group, or user.
Allows a user to set the resource limit for the calling process.
Allows a user to mount file systems. For z/os 1.13 and above, an additional check for the BPX.CAHFS.USERMOUNT resource occurs if the check for BPX.CAHFS.MOUNT fails.
Allows a nonprivileged user to mount a file system. If the check for BPX.CAHFS.MOUNT resource fails, BPX.CAHFS.USERMOUNT is checked. BPX.CAHFS.USERMOUNT differs from BPX.CAHFS.MOUNT support because with UNIX System Services extra criteria are required for the user to be able to mount the file system. These criteria include needing to mount on an empty directory, needing permission to the mount point directory and the file system being mounted, and others. For a complete list of these criteria, see IBM's z/OS UNIX System Services Planning.
Because the user must own or have permission to the file system being mounted and the mount point directory, the following permits are required:
Example:
mount -t zfs -f OMVS.HFS.BOBFILE -a unmount -s nosetuid /user/bob
For user BOB to mount OMVS.HFS.BOBFILE at the mount point /user/bob using the above OMVS shell command, the following three permits are required:
TSS PERMIT(BOB) IBMFAC(BPX.CAHFS.USERMOUNT) ACCESS(READ) TSS PERMIT(BOB) HFSSEC(OMVS.HFS.BOBFILE) ACCESS(ALTER) TSS PERMIT(BOB) HFSSEC(/USER.BOB) ACCESS(ALTER)
Allows a nonprivileged user to unmount a file system. Otherwise, for UNIX System Services, nonprivileged users cannot unmount a file system that they did not mount.
Allows a user to control and debug another process. Although the user need not be defined as a superuser to use this function, access to this resource does not give the user more authority than a superuser would have. If the user attempts to debug a program running with SETUID or SETGID (that is, a program that switches user identification), access to the function is denied.
Allows a user to create a hard link to an existing file. A hard link is essentially another name for the same file data. If the original file is removed, the hard link still points to the file data. The data is not deleted until the last link is removed. The user requires a permission with ACCESS(ALTER) to the HFS file resource for both the original file and the link file. When data associated with a hard link is accessed, the CA‑ENF/USS service requests the file name from USS. Regardless of the actual path accessed, the file name that is returned may be the hard link name or the original file name. Therefore, when a hard link exists, you must maintain permissions for both the link name and the original name.
Allows a user to create an external link to an object outside of the file system, such as an MVS data set. An external link is a file that contains the name of an external object. If the external object is removed, the external link still contains the name of the nonexistent object.
Allows a user to create a symbolic link to an existing file. A symbolic link is a file that contains the name of another file. If the original file is removed, the file data is deleted but the symbolic link still contains a pointer to the nonexistent file. Symbolic link names are validated when the link is created and deleted. All other accesses are validated with the original file name. In addition to this resource, the user must also have a PERMIT with ACCESS(ALTER) to the HFS file resource for both the original file and the link file.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|