pagsh - Creates a new PAG
The pagsh command creates a new command shell (owned by the issuer of the command) and associates a new process authentication group (PAG) with the shell and the user. A PAG is a number guaranteed to identify the issuer of commands in the new shell uniquely to the local Cache Manager. The PAG is used, instead of the issuer's UNIX UID, to identify the issuer in the credential structure that the Cache Manager creates to track each user.
Any tokens acquired subsequently (presumably for other cells) become associated with the PAG, rather than with the user's UNIX UID. This method for distinguishing users has two advantages.
It means that processes spawned by the user inherit the PAG and so share the token; thus they gain access to AFS as the authenticated user.
In many environments,
printer and other daemons run under identities (such as the local superuser
root) that the AFS server processes recognize only as
Unless PAGs are used,
such daemons cannot access files in directories whose access control lists (ACLs) do not extend permissions to the system:anyuser group.
It closes a potential security loophole: UNIX allows anyone already logged in as the local superuser
root on a machine to assume any other identity by issuing the UNIX su command.
If the credential structure is identified by a UNIX UID rather than a PAG,
then the local superuser
root can assume a UNIX UID and use any tokens associated with that UID.
Use of a PAG as an identifier eliminates that possibility.
Each PAG created uses two of the memory slots that the kernel uses to record the UNIX groups associated with a user. If none of these slots are available, the pagsh command fails. This is not a problem with most operating systems, which make at least 16 slots available per user.
In cells that do not use an AFS-modified login utility, use this command to obtain a PAG before issuing the klog command (or include the -setpag argument to the klog command). If a PAG is not acquired, the Cache Manager stores the token in a credential structure identified by local UID rather than PAG. This creates the potential security exposure described in DESCRIPTION.
If users of NFS client machines for which AFS is supported are to issue this command as part of authenticating with AFS, do not use the fs exportafs command's -uidcheck on argument to enable UID checking on NFS/AFS Translator machines. Enabling UID checking prevents this command from succeeding. See klog(1).
If UID checking is not enabled on Translator machines,
then by default it is possible to issue this command on a properly configured NFS client machine that is accessing AFS via the NFS/AFS Translator,
assuming that the NFS client machine is a supported system type.
The pagsh binary accessed by the NFS client must be owned by,
and grant setuid privilege to,
the local superuser
The complete set of mode bits must be
This is not a requirement when the command is issued on AFS client machines.
However, if the translator machine's administrator has enabled UID checking by including the -uidcheck on argument to the fs exportafs command, the command fails with an error message similar to the following:
Warning: Remote setpag to <translator_machine> has failed (err=8). . . setpag: Exec format error
In the following example, the issuer invokes the C shell instead of the default Bourne shell:
# pagsh -c /bin/csh
fs_exportafs(1), klog(1), tokens(1)
IBM Corporation 2000. <http://www.ibm.com/> All Rights Reserved.
This documentation is covered by the IBM Public License Version 1.0. It was converted from HTML to POD by software written by Chas Williams and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell.