R.Többicke, CERN/CN
preliminary, incomplete Version 0.2, revised April 24, 1996
Quite often operations which require special privileges are to be performed by users who are normally not granted those privileges. The mechanism granting the necessary privileges may simply be too coarse - in the Unix environment almost every command of vaguely administrative nature requires root privilege, a privilege which besides enabling a user to perform comparatively harmless operations such as defining a new printer or adding a new user also gives him complete control over the remainder of the machine. Or the operation may be delicate enough that it should not be executed by a non-specialist without performing other operations before or after.
The Unix root privilege has another drawback: it is controlled by a single password, making it difficult to manage and to track who is privileged at any given time and who has performed what operation.
The Unix root privilege also turns out to be largely insufficient in a distributed computing environment: it gives control over the individual Unix system, but in a complex networked environment services usually span systems and implement privilege schemes which do not relate to 'local' root authority.
arc has been inspired by the sysctl facility written at IBM T.J.Watson in Yorktown Heigths, NY.
It basically works as follows:
arc is implemented as two modules, the requestor module arc (client) and the server module arcd.
The requestor is executed as a normal unix command, specifying the server's hostname, processing flags, and the operation to be executed on the server. The command's standard input is connected to the server process' standard input, making it possible to pass arbitrary data just like in a 'rsh' (remote shell) command.
The arcd server is started by the Unix inetd super-daemon for every new request. The user's requested operation is passed as parameters on the command line, and the standard input and output are connected to the client 'arc' command's input and output. Variables in the server's environment specify the Kerberos identity of the requesting user, the hostname the command is issued from, and whether the connection uses encrypted or clear-text transfer (stdin/stdout). The specified script is executed under the Unix uid of 0.
In case AFS support has been compiled into ARC, a setpag() is executed before starting up the interpreter. This way any server code can safely request privileged AFS tokens which will not be inherited by subsequent invocations.
In the standard configuration the server starts a PERL interpreter with a standard initialization script. The functionality described hereafter applies only when this script is used.
Operations (arc-subcommands) are represented by files of the form <subcommand>.arc in standard directories. The list of directopries searched is coded into the initial script as the contents of the PERL array ARCETC.
The file is loaded into the PERL interpreter using require. The command file should do two things:
In case no <subcommand>.arc procedure is found, and if the issuer has the ACL privilege, the complete command is executed as a PERL command (using eval) under root privilege. A simple way to reboot a remote machine would therefore be
arc -h <remote-node> system reboot
Upon invocation of the command procedure the following environment variables are defined:
A few subcommands have been predefined:
The following subroutines are available for calling from command processing subroutines.
and:
Privileged AFS commands, mainly called by afs_admin: acl fs mkdir pv pv-list vos
operations on normally read-only directories
The batch job token extension works basically as follows
The llsubmit command has to be modified in order to include the current PGP-encrypted AFS token in the job. The token is identified by a '##BATCHKAUTH=' line near the beginning of the jobs script. This implies that the job must be a script, submitting a module (e.g. /bin/ls) will not work.
The modification can either by done by creating a front-end which copies the job into a temporary file and then 'llsubmit's it or by using a submitfilter exit. The filter extracts the current AFS Token using GetToken and encrypts it using PGP.
There are at least two places in LoadLeveler where the hook to activate the token can be placed.
The most convenient place is the llcheckpriv module. This program is called before the job output files are opened. The current job script resides in the current directory. We replace llcheckpriv by a shell script that calls the setuid program batchauth and then calls the original llcheckpriv program. batchauth reads the job file and extracts the PGP-encrypted token, and passes it to the token extension server. If all goes well, it comes back with a valid AFS token in the Kernel cache from where on the original llcheckpriv module will faithfully do its business.
The official place where sub an exit should be placed is in the job prolog (JOB_PROLOG config variable). However, on some architectures (e.g. AIX) LoadLeveler has built-in AFS support without token extension. On AIX the AFS token is set up after the job prolog is run, which means that the freshly created long-lived token is promptly overwritten by the (usually expired) user's token upon the time of submit.
The LoadL_starter has to be run in a PAG (e.g. using pagsh), otherwise the token will end up Unix UID-based. In that case an 'unlog' issued by a user logged into the same machine as his job would unlog the job as well.
arc has been used to implement the acrontab command, which allows scheduling of cron jobs with valid AFS tokens.
Cron entries are kept on a central server, whereas the commands are executed on a machine of the user's choice. The format of the crontab entries are the usual SysV (to be precise: AIX) ones, except that the command MUST start with the IP node name of the node the command is to be executed on. This looks almost like an 'rsh' with a hostname alias, e.g.:
18 12 * * * rsrtb /usr/afsws/bin/tokens; ls -l; envexecutes 'tokens', 'ls' and 'env' on rsrtb every day at 12:18 (not very useful by the way). The output of the command is returned as a mail message to wherever the user's .forward file (in AFS) points to, default is userid@afsmail.
The command syntax is similar to the normal System V crontab command:
Prerequisites:
User's cron table entries are passed to a central server using an authenticated arc connection. The server creates entries for the internal acron command which is passed the user's Kerberos principal and the target node name. The user's command(s) and all parameters are passed on stdin.
acron is started by cron as root on the server. It creates an AFS token for the user based on the passed Kerberos principal and opens an authenticated encrypted arc connection to the target node where it invokes the arc subcommand acron and passes the user's token, command and arguments.
The acron subcommand switches to the user's account and home directory, reads the AFS token over the (encrypted) communications channel and starts a shell to execute the command. Command results are sent back to the server who collects them in a temporary file which is mailed to the user unless empty.
ARC - Authenticated Remote Control
This document was generated using the LaTeX2HTML translator Version 96.1-e (April 9, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 arc.tex.
The translation was initiated by Rainer TOBBICKE on Wed Apr 24 18:35:49 METDST 1996
Further updates made by straight edit of the resulting file. Last updated Jan 15th, 2004