z/OS UNIX System Services File System Interface Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Security responsibilities and considerations

z/OS UNIX System Services File System Interface Reference
SA23-2285-00

The security structure of z/OS UNIX consists of two parts: the user's identity and the file's access control information. A VFS server is primarily concerned with the user's identity.

As a z/OS UNIX "superuser," a VFS server has free access to all z/OS UNIX resources. Consequently, it is the VFS server's responsibility to make sure that everything it does on behalf of a particular end user is done under the authority of that end user.

For a VFS server that is directly invoked by a local user, such as by a command, the simplest thing to do is to require that the invoker be a superuser. If the VFS server runs as a setuid program or is a more traditional client/server type of server, the rest of this topic applies.

It is expected that a VFS server will assume the identity of its end user while making calls to z/OS UNIX services. This consists of several steps:
  1. End users must be defined to both MVS™ and z/OS UNIX. They will have both an MVS user ID and a z/OS UNIX UID-GID pair.
  2. The VFS server must know the MVS user ID of the end user.
  3. The VFS server invokes SAF services to set up a security environment based on that MVS user ID.

    RACROUTE REQUEST=VERIFY,ENVIR=CREATE is used to initialize the MVS part of the security environment, and Init_USP is used to add the z/OS UNIX information.

    For acceptable performance, a VFS server should maintain enough state information so that it could save this security environment for a given end user and not have to re-create it on every request.

  4. Before calling z/OS UNIX services for an end user, the VFS server updates its address space or task to assume the security environment that was set up by RACROUTE and Init_USP, by storing the ACEE from RACROUTE in the security environment field of the Task Control Block (TCBSENV).

    If this is a read or write function, the VFS server must decide whether file access checking is to be performed by the system. If the VFS server maintains enough state information to recognize the first reference by a particular end user to a particular file object, it can limit the overhead of access checking to that first reference. Otherwise, every read or write must be access checked. Other types of calls are unconditionally access-checked if access control is defined for the call.

    After the call, or sequence of calls, for that end user, the VFS server reverts to its own security environment or sets up for the next end user.

  5. When an end user is finished using the VFS server, the VFS server invokes RACROUTE REQUEST=VERIFY,ENVIR=DELETE to free the security environment.

Access control checks are performed by the PFSs that own the data. These checks are based on information that is associated with each individual file. The VFS server does not control these access checks except for read and write operations.

For more information about these interfaces, seez/OS Security Server RACF Callable Services.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014