The Accounts stage of the Community Accounts project consists of creating all tools necessary for implementation of a community account on a UNIX-like system. These utilities will be highly configurable to facilitate a wide variety of possible implementation styles. This stage of the project does not encompass concerns such as long-term storage and job auditing. Please see the Community Accounts Stages document for an overview of all stages involved in this project.

1. A suite of chroot environment management utilities
2. A community shell application
3. A community environment management utility
4. A combined package in source and binary formats
5. A GRAM patch to execute jobs through the user's shell

The chroot_jail suite of utilities can create, manipulate, and remove chroot jail environments.

Jail creation and management utilities are necessary because creation of a properly configured jail environment is a non-trivial task. For example, shared libraries must be included correctly, the /etc of the jailed environment must be configured correctly, and certain shared libraries that are not specifically dependencies of any binaries must be included for some general UNIX functions to work correctly. Additionally, certain conditions (such as setuid root binaries) must be avoided in order to keep the jailed environment secure.

These utilities use flatfile databases to track dependencies so that files can be easily added and removed from the jail. The databases are stored in a Berkeley-format DB file using the perl DB_File module.

A global jail configuration file, chroot_jail.conf, will describe how the jail check routines process files in each jail. The location of this file can be specified at compile-time.

It should be noted that utilities already exist to generate jail environments, such as jailkit and vserver, however these applications do not allow for the wide variety of configuration and management options, nor are they as widely supported among UNIX systems. The chroot_jail suite will install and function on any POSIX-compliant system with perl 5.8 installed.

The commsh general-purpose community shell includes the abilities to perform a change root (chroot) operation upon startup; create a dynamic account (by setting the user's uid to a dynamically allocated uid); directly launch a command from a configurable list of valid commands; and launch a more conventional (or restricted) shell. Each of these options is fully configurable. All logging takes place using the syslog logging mechanism.

Configuration takes place by parsing commsh.conf for a set of configuration directives. Two of these directives allow you to load additional configuration files (optionally based on the community user running the shell.) If a directive that takes only one value appears twice, the latter value will overwrite any prior values. The location of this file is determined at compile time.

Of particular note are the dynamic account options. If enabled, commsh has the ability to manage a range of valid uid values that it will assign to sessions dynamically. Each dynamic account instantiation can create a copy of a template home directory, and will expire and be automatically removed after a configurable length of time has passed. Also, if configured a token will be generated that allows a user to re-use a given dynamic account for multiple sessions.

Expired dynamic accounts can either be reaped on every run of commsh (if configured), or they can be reaped by running commsh --reap as root at any time (such as from a cron job).

Certain options, such as changed root environments and dynamic accounts, are only available if the commsh binary is setuid root. If the binary is not setuid root, configuration directives related to these options will be ignored. The setuid root bit is dropped immediately after selecting a dynamic uid and changing to a new root directory.

A simple shell-script utility facilitates generation of community shell environments. This script will generate configuration files, use the chroot_jail suite of utilities to create jailed environments (if desired), and make appropriate additions to /etc/passwd and /etc/group. This utility can generate multiple community accounts, and can be used later to manage these accounts.

The above utilities will be packaged and available as separate and combined packages. These packages will be available both in source format as a tarball, and in binary format in a variety of UNIX package styles.

It is unclear at this point exactly how this patch will need to be constructed. The most likely candidate appears to be modifications to fork_starter.c coupled with a new configuration parameter for globus-fork.conf. This parameter should be of the form "use_user_shell=true", and if set it should force fork_starter to execute commands through the user's defined shell. Assuming that all job managers do (or can be made to) use fork_starter when they launch jobs, this should work as desired.

Further research into the GRAM execution flow and how it interacts with existing and potential new job schedulers is required.

This document, and all referenced documents, should be considered as works in progress. They are neither definitive nor complete, and may change with final implementation.

Some of the functionality implemented by these deliverables is already partially available in existing software. Examples of such include jailkit, Linux-VServer, and chrsh. However, these utilities do not meet all requirements of this stage of the Community Accounts project. Where useful, we will utilize already existent code and ideas (with proper permission and citation) in the development of these utilities.