|
commsh.conf − Community Shell configration file |
|
commsh.conf contains a list of directives that determine the behavior of commsh, the Community Shell. |
|
A directive is of the form: |
|
DirectiveName [Value [Value ...]] |
|
Each Value can be either a boolean keyword (true, on, yes versus false, off, no), an integer (octal and hexadecimal forms are allowed, e.g. 0777 or 0x4A), or a string. Multi-word strings must be enclosed in quotation marks (e.g "one two three"), and both quotation marks and newlines can be escaped using \. If a directive is given without any values, a true boolean value is assumed. Blank lines and lines starting with a # (comments) are ignored. |
|
An * denotes directives that are not currently implemented. |
|
General |
|
ReadConfig FILE |
|
Read the configuration file found at FILE as if it were appended to the end of the main configuration file. Note that tildes in FILE are expanded. |
|
ReadUserConfig UID/USERNAME FILE |
|
Behaves as ReadConfig if UID/USERNAME matches the current user. |
|
AllowUser UID/USERNAME |
|
Allows the given user to run commsh. By default, nobody is allowed access. The special value of may be provided to allow any user that has not been explicitly denied (see DenyUser below). |
|
DenyUser UID/USERNAME |
|
Explicitly deny the given user from running commsh. This option has no effect unless has been specified. |
|
AssignUID UID |
|
Assign a static UID to be assigned. (By default, the UID of the user is preserved.) This option is ignored if dynamic account generation is enabled (see below). |
|
Change Root |
|
ChrootPath [PATH/BOOL] |
|
If BOOL is true or a PATH is provided, chroot functionality is enabled. The default path is the user’s home directory, and tilde expansions in a provided path are performed. Before chroot is called, the path will be checked for security risks (see CheckChroot below). |
|
CheckChroot [CHECK [CHECK ...]] |
|
Before chrooting to a jailed environment, perform the specified checks. Possible checks include: suidroot |
|
Check for files setuid root |
|
suid |
|
Check for files with the setuid bit set |
|
sgid |
|
Check for files with the setgid bit set |
|
block |
|
Check for block devices |
|
char |
|
Check for character devices |
|
socket |
|
Check for UNIX sockets |
|
fifo |
|
Check for FIFO pipes |
|
mount |
|
Check for mount points. |
|
all |
|
Perform all checks (default) |
|
CheckAllowDevice DEVICE |
|
Allow the given DEVICE to exist within the jail. DEVICE should refer to a file in the real filesystem (not the jailed environment). The actual path to this file is not relevant, as the only checked characteristics are the file’s mode, rdev, uid and gid. This only matters for block and character devices, sockets and FIFO pipes (the latter two of which don’t have an rdev to check), and then only if the corresponding CheckChroot parameter has been set. |
|
Dynamic Account Generation |
|
*AssignDynamicUID MIN MAX |
|
Enables generation of dynamic accounts and specifies the range of UIDs (incluive) to use during generation. If MIN or MAX begins with a + or - sign, then its value will be interpreted relative to the user’s real UID. For example, if the user’s UID is 1000 and the range is [1,100], then UIDs 1001 through 1100 will be used. If no UIDs within the range are available, the login will fail and an error will be recorded. |
|
*DynamicCachePath PATH |
|
Specify the location to store cached dynamic account information. This inofmration is used to reap old dynamic accounts as well as to store authentication tokens for reauthentication to an existing account. ~ expansion will take place based on the user’s pre-chroot home directory. This option must be specified for dynamic account generation to work. |
|
*DynamicHome PATH |
|
Specifies the path to use as the home directory for a dynamically generated account. ~ expansion will take place based on the user’s post-chroot home directory, and the following other escape sequences will function: %u |
|
Post-chroot username |
|
%d |
|
Dynamically assigned UID |
|
%n |
|
Original UID |
|
%~ |
|
Post-chroot home directory (same as ~) |
|
If the specified directory already exists, then it will still be used but it won’t be instantiated from a template (see DynamicHomeTemplate below). |
|
*DynamicHomeTemplate PATH |
|
Specifies the path to use as a template for dynamically generate home directories. All files and directories in the specified template will be copied into the newly created directory. If this option is not specified, dynamically generated home directories will be empty. |
|
*DynamicShell SHELL |
|
Specifies the shell to use after assigning a dynamic UID. If not specified, the shell for the original UID is used (as determined from within the chroot jail) as long as that shell isn’t named commsh. If no such shell can be determined, /bin/sh is used by default. |
|
*DynamicExpiration TIMESPAN |
|
Specifies the length of time that a dynamic account is allowed to exist before being removed from the system (aka reaped). Accounts are not guaranteed to be removed after this length of time has passed, but they are guaranteed not to be removed earlier than this. This time is measured from the most recent successful login to the account, and not from logout. TIMESPAN must be specified as an integral number of minutes, and defaults to 10080 (one week.) |
|
*DynamicAutoReap True/False |
|
If true, expired dynamic accounts will be reaped every time that commsh is run. Otherwise, commsh --reap must be run in order to delete expired accounts and free up dynamic UIDs. |
|
*DynamicAllowReuse True/False |
|
If true, authentication tokens will be generated for dynamic accounts allowing the accounts to be reused. These tokens will be sent as part of the initial login message, and reauthentication is possible by specifying them in the command string. The exact format is: where COMMAND can be left blank. |
|
Access Methods |
|
*LaunchShell True/False |
|
If true, exec the user’s shell after authentication, passing to it any command parameters. If false, commands will be executed directly as long as they match a DirectAccess directive (see below). |
|
*AllowSftp True/False |
|
If true, sftp access will be allowed to the account. If a chroot jail is in use, the sftp subsystem must exist within the jailed environment. |
|
*DirectAccess CMD |
|
Allow direct access to a given command. This has no effect if LaunhcShell is enabled. The format of the commands is described in COMMAND PARAMETERS (see below). |
|
The command parameters used by the DirectAccess directive conform to the following specifications: The command issued must match the specified command exactly. If command parameters are expected, they must be included explicitly in the format of the command. Wildcard matching is included, but wildcards will not match spaces. Optional parameters can be specified by enclosing them in brackets ([]). If a wildcarded parameter is preceded by a tilde (~), then only files in the user’s home directory can be specified. A final parameter of ** specifies that the user can add any number of additional parameters to the end of the command. |
|
Examples: |
|
DirectAccess /bin/rbash |
|
Allow the user to launch a restricted bash environment without parameters |
|
DirectAccess /usr/bin/whoami [--*] |
|
Allow the user to execute whoami with an optional -- option |
|
DirectAccess /bin/cat ~* |
|
Allow the user to execute cat on any file in the user’s home directory |
|
DirectAccess /usr/bin/jobmanager ** |
|
Allow the user to execute jobmanager with any parameters |
|
commsh(1) Community Shell (commsh) is a component of the NCSA Restricted Community Accounts project. Project website: http://security.ncsa.uiuc.edu/research/commaccts |
|
Kevin J. Price <kjprice@ncsa.uiuc.edu> National Center for Supercomputy Applications (NCSA), http://www.ncsa.uiuc.edu/ |
|
Copyright (c) 2005-2006, The Board of Trustees of the University of Illinois. All rights reserved. |