GNU Rush
	Restricted User Shell	Sergey Poznyakoff

• Main
• Downloads
• Documentation

4.4 Rule

The rule statement configures a GNU rush rule. This is a block statement, which means that all statements located between it and the next rule statement (or end of file, whichever occurs first) modify the definition of that rule.

The syntax of the rule statement is:

Configuration: rule tag

The tag argument is optional. If it is given, it supplies a tag for the rule, i.e. a (presumably unique) identifier, which is used to label this rule. Rush uses this tag in its diagnostic messages. For rules without explicit tag, Rush supplies a default tag, which is constructed by concatenating ‘#’ character and the ordinal number of rule in the configuration file, in decimal notation. Rule numbering starts from ‘1’.

Each rule group can contain a number of statements that control what kind of requests match that rule and what actions are taken when the rule is matched. Arguments to this statements can refer to command line arguments and other parts of the request.

4.4.1 The Request

User request consists of the user passwd entry, the command line supplied to rush, and environment variables. The request is analyzed and can be eventually modified by rules in rush configuration file. Rules access parts of the request using variables.

There are four classes of variables. All of them share the same namespace and are accessed using the same syntax.

4.4.1.1 Positional variables

Rush performs word splitting using the same rules as sh. Statements in the configuration file refer to command line arguments (words) by their index, using positional variables. A positional variable can have the following forms:

 $n
 ${n}

where n is the variable index. The form with curly braces must be used if n is negative (see below) or greater than 9.

Arguments are numbered from ‘0’. The name of the command is argument ‘$0’. Consider, for example, the following command line:

/bin/scp -t /upload

Word splitting phase results in three positional variables being defined:

These values can also be referred to using negative indexes. They refer to words in the reverse order, as illustrated in the following table (notice the use of curly braces):

Notice also, that negative indexes are 1-based.

One final note about the ‘$0’ variable. Immediately after word splitting it refers to both the executable program name and the 0th argument that will be passed to that program (argv[0]). Most of the time the two values coincide. However, the rule can modify either value, so that they become different. Whether modified or not, the actual name of the program to be run is kept in the request variable ‘$program’ (see the following section).

4.4.1.2 Request variables

The following variables can be used to refer to various parts of the user request:

4.4.1.3 Environment variables

Environment variables are accessed using the same syntax as the rest of the variables. Rules can modify them using the setenv, clrenv and keepenv statements (see Environment).

4.4.1.4 User-defined variables

In addition to the built-in variables, arbitrary variables can be defined and used in the configuration file. These user-defined variables are defined using the set statement (see set) and are normally used to pass information between rules. They are invisible to whatever command rush executes as the final result of processing.

4.4.1.5 Variable Expansion

Most statements in the configuration file undergo variable expansion prior to their use. During variable expansion, references to variables in the string are replaced with their actual values. A variable reference has two basic forms:

  $v
  ${v}

where v is either the name of the variable (request, environment, or user-defined), or the index of the positional variable. The notation in curly braces serves several purposes. First, it is obligatory if v is an index of the positional variable that is negative or greater than 9. Secondly, it should be used if the variable reference is immediately followed by an alphanumeric symbol, which will otherwise be considered part of it (as in ‘${home}dir’). Finally, this form allows for specifying the action to take if the variable is undefined or expands to an empty value.

The following special forms are recognized:

${variable:-word}

Use Default Values. If variable is unset or null, the expansion of word is substituted. Otherwise, the value of variable is substituted.

${variable:=word}

Assign Default Values. If variable is unset or null, the expansion of word is assigned to variable. The value of variable is then substituted.

${variable:?word}

Display Error if Null or Unset. If variable is null or unset, the expansion of word (or a message to that effect if word is not present) is output to the current logging channel. Otherwise, the value of variable is substituted.

${variable:+word}

Use Alternate Value. If variable is null or unset, nothing is substituted, otherwise the expansion of word is substituted.

These constructs test for a variable that is unset or null. Omitting the colon results in a test only for a variable that is unset.

When expanding a variable reference, the variable name is first looked among the request variables. If it is not found, it is looked up in the user-defined variable list. If it is not there, the look up in the environment is attempted.

If the variable name is not found in any of these lists, the default rush behavior is to report the error of ‘config-error’ class (see Error Messages) and exit. To gracefully handle such cases, use the default value construct, defined above. For example, the following statement safely appends the string ‘/opt/man’ to the value of the MANPATH environment variable:

setenv MANPATH = "${MANPATH:-""}${MANPATH:+:}/opt/man"

The ‘${MANPATH:-""}’ reference ensures no error is reported if the variable is undefined. The ‘${MANPATH:+:}’ reference appends a semicolon to the value, if the variable is defined. Finally the string ‘/opt/man’ is appended to the resulting value.

Another way to gracefully handle undefined variables, is to use the expand-undefined global setting. If you place the following statement at the beginning of your configuration file, any undefined variable will be silently expanded to empty string:

global
  expand-undefined true

This statement affects variable expansion in statements that follow it in the configuration file. So you can place it in some point after which this behavior is needed, and then disable it where it is no longer desired, by using the following global statement:

global
  expand-undefined false

4.4.2 Matching Conditions

rule: match expr

The match statement defines conditions that decide whether the rule matches the particular request. Its argument is a simple expression or a boolean expression involving several simple expressions.

A simple expression is either a comparison or membership test.

4.4.2.1 Comparisons

A comparison expression is:

lhs op rhs

here, lhs (left-hand side) is a string (quoted or unquoted), or a variable reference (see Lexical Structure), rhs (right-hand side) is a string or number, and op is one of the following binary operators:

Prior to evaluating simple expression, its left-hand side undergoes variable expansion and backreference interpretation. In contrast, the right-hand side is always treated verbatim.

For example the following rule will match any request with 2 or more arguments (recall, that the command name itself is counted as one of the arguments):

rule
  match $# >= 2

The ‘==’ and ‘!=’ can operate both on strings and on numbers. When applied to strings the ‘==’ means byte-to-byte equality, e.g.

  match $0 == "/bin/ls"

will match requests with ‘/bin/ls’ as the command name.

The ‘~’ and ‘!~’ operators implement regular expression matching.

The expression ‘lhs ~ rx’ yields ‘true’ if lhs matches regular expression rx. E.g.

  match $command ~ "^scp (-v )?-t /incoming/(alpha|ftp)"

The ‘!~’ evaluates to ‘true’ if lhs does not match the regular expression in the rhs.

If the regular expression contains parenthesized groups, subsequent commands can refer to the strings that matched the groups using the backreference notation ‘%n’, where n is 1-based index ordinal number of the group in the regular expression (see backreference). The reference ‘%0’ expands to the entire matched string. For example:

rule chdir
  match $command "^cd (.+) && (.+)"
  chdir %1
  set command = %2
  fall-through

It splits the compound command into the working directory and the command itself. Then it remembers the name of the working directory (first parenthesized group – ‘%1’) for changing to it later (see chdir) and resets the command line to the part of the string that follows the ‘&&’ token. Finally, it passes control to another rules (see Fall-through).

4.4.2.2 Membership operators

Membership operators check if their argument is a member of some set of values. There are two such operators.

lhs in ( args )

The in operator evaluates to ‘true’ if lhs is listed in args, which is a whitespace-separated list of strings. For example:

  match $0 in ("scp" "rsync")

The group operator evaluates to ‘true’ if the requesting user is a member of at least one group listed in its right-hand side. It can have two forms:

group grp

Evaluate to ‘true’ if the user is a member of the group grp. The group can be given either by its name or GID.

group ( list )

Evaluate to ‘true’ if the user is a member of one of the groups in whitespace delimited list. Members of list are group names or GIDs.

4.4.2.3 File system tests

File system tests check file types and ownership. They are similar to options to test shell command:

-b file

file exists and is block special

-c file

file exists and is character special

-d file

file exists and is a directory

-e file

file exists

-f file

file exists and is a regular file

-g file

file exists and is set-group-ID

-G file

file exists and is owned by the primary group of the current user.

-h file

-L file

file exists and is a symbolic link

-k file

file exists and has its sticky bit set

-L file

file exists and is a symbolic link (same as -h)

-O file

file exists and is owned by the current user

-p file

file exists and is a named pipe

-r file

file exists and read permission is granted

-s file

file exists and has a size greater than zero

-S file

file exists and is a socket

-u file

file exists and its set-user-ID bit is set

-w file

file exists and write permission is granted

-x file

file exists and execute (or search) permission is granted

4.4.2.4 Boolean expressions

Simple expressions can be combined into complex conditions using boolean operators:

Arguments to these operators can be either simple expressions or another boolean expressions. The operators in the table above are ordered by their precedence. As in most programming languages, parentheses can be used to enforce the desired order of evaluation.

Both binary operators implement shortcut evaluation.

For example, the following rule will match if the command name contains ‘git-receive-pack’ or ‘git-upload-pack’ and either the UID is 100 or the user is a member of the group ‘git’:

rule
  match $0 ~ "git-(receive|upload)-pack" && \
             ($uid == 100 || group "git")

Notice the use of parentheses to enforce proper evaluation order. The ‘&&’ operator has higher priority than ‘||’. Without parentheses the rule would match if either the command name matched the regexp and the user ID was 100, or if the user was a member of the ‘git’ group, no matter what command was issued.

4.4.3 Modifying variables

Rules can change or unset variables. Two separate groups of statements are provided to that effect. The set, unset, and map statements operate on positional, request, and user-defined variables. The setenv, unsetenv, clrenv, and keepenv statements modify the environment. These will be discussed in a separate subsection (see Environment).

Modifications to positional and request variables deserve a special explanation.

The only two request variables that can be modified (but not unset) are $command and $program.

Positional variables and the $command request variable are mutually dependent. If the $command is modified, the word splitting is applied to it and resulting words are assigned to the positional variables. Similarly, any modifications to positional variables trigger rebuilding of the $command variable from the modified arguments. Both operations are run immediately after the change that triggered them. Notice, however, that any transformations, including variable modifications, are executed after match statements have been evaluated, so that match always operates on unchanged variables, no matter where in the rule you place it,

If the rules result in accepting the request, then modified $command becomes the actual command that rush will execute.

Obviously, none of the request variables can be unset. You can however, unset a positional variable (excepting ‘$0’). It is equivalent to removing the corresponding argument from the command line.

4.4.3.1 The set statement

The set statement modifies the value of a positional, request, or user-defined variable.

rule: set name = value

rule: set [n] = value

Sets the variable name to value. Prior to use, value undergoes backreference interpretation (see backreference) and variable expansion (see Variable expansion).

The second form assigns to the positional variable ‘$n’. It is discussed in more detail in Transformations.

rule: set name = value ~ s-expr

rule: set [n] = value ~ s-expr

Applies the sed search-and-replace expression s-expr to value and assigns the result to the variable name or argument n. Both value and s-expr are subject to variable expansion and backreference interpretation.

rule: set name =~ s-expr

rule: set [n] =~ s-expr

Applies the sed-like search-and-replace expression s-expr to the current value of the variable name and stores the resulting string as its new value. Prior to use, s-expr undergoes backreference interpretation (see backreference) and variable expansion (see Variable expansion). This is a shortcut for

set name = ${name:-""} ~ s-expr

Second form modifies the value of the positional variable ‘$n’. This statement is a shortcut for

set [n] = ${n:-""} ~ s-expr

See Transformations, for a detailed discussion.

The transformation expression, s-expr, is sed-like replace expression of the form:

s/regexp/replace/[flags]

where regexp is a regular expression, replace is a replacement for each part of the input that matches regexp and flags are optional flags that control the substitution. Both regexp and replace are described in The ‘s’ Command in GNU sed.

As in sed, you can give several replace expressions, separated by semicolons.

Supported flags are:

‘g’

Apply the replacement to all matches to the regexp, not just the first.

‘i’

Use case-insensitive matching

‘x’

regexp is an extended regular expression (see Extended regular expressions in GNU sed).

‘number’

Only replace the numberth match of the regexp.

Note: the POSIX standard does not specify what should happen when you mix the ‘g’ and number modifiers. Rush follows the GNU sed implementation in this regard, so the interaction is defined to be: ignore matches before the numberth, and then match and replace all matches from the numberth on.

Normally, the s-expr is a quoted string, and as such it is subject to backslash interpretation. It is therefore important to properly escape backslashes, especially in replace part. Consider this example:

set bindir = $program ~ "s/(.*)\\//\\1/"

The intention is to extract the directory part of the executable program name and store it in the variable ‘bindir’. Notice, that each backslash is escaped, so that the actual string that is compiled into a regular expression is

s/(.*)\//\1/

4.4.3.2 The insert statement

The insert statement inserts new positional argument at a given position. Its syntax is similar to set:

rule: insert [n] = value

rule: insert [n] = value ~ s-expr

Shift arguments starting from n one position to the right (so that n becomes n+1 etc.) and insert value at argv[n].

In the second form, the value to be inserted is computed by applying sed-expression s-expr to value.

Both value and s-expr are subject to variable expansion and backreference interpretation.

Example using this statement to insert the --root=/tmp argument at position 1:

insert [1] = "--root=/tmp"

Note that when inserting multiple arguments (e.g. an option with a value), you have two possibilities. First, you can insert each argument at its corresponding position. For example, to insert two arguments ‘--root’ and ‘/tmp’ starting at position 1, one can use:

insert [1] = "--root"
insert [2] = "/tmp"

Otherwise, you can revert the arguments and insert them at the same position, as shown in the example below:

insert [1] = "/tmp"
insert [1] = "--root"

4.4.3.3 The unset statement

rule: unset name

Unset the variable name.

rule: unset n

Unset the positional argument n (an integer number greater than 0), shifting the remaining arguments one position left. The effect is the same as from delete (see delete).

4.4.3.4 The remopt statement

The remopt statement removes from the command line all occurrences of the supplied option.

rule: remopt sopt

rule: remopt sopt lopt

Remove from the command line all occurrences of the short option described by sopt. The sopt argument is the short option letter, optionally followed by a colon if that option takes a mandatory argument, or by two colons if it takes an optional argument.

Optional lopt supplies a long option equivalent to sopt. If no short option equivalent exists, use ‘_’ as sopt, eventually followed by ‘:’ or ‘::’.

For example, to remove all occurrences of the -r (--root) option that takes a mandatory argument, use:

remopt r: root

4.4.3.5 The delete statement

Another statement modifying the command line is delete:

rule: delete n

Delete nth argument.

rule: delete i j

Delete positional parameters between ‘$i’ and ‘$j’, inclusive.

Neither form can be used to delete the program name (‘$0’).

For example, the following statement deletes all arguments from the command line, except for the program name:

delete 1 -1

To delete a single argument, unset can also be used. The following statements have the same effect:

delete 2
unset 2

4.4.3.6 The map statement

rule: map name file delim key kn vn

rule: map [n] file delim key kn vn default

The ‘map’ statement uses file lookup to find a new value for the variable name (or, in its second form, for the positional variable ‘$n’).

Arguments are:

file

Name of the map file. It must begin with ‘/’ or ‘~/’. Before using, the file permissions and ownership are checked using the procedure described in security checks.

delim

A string containing allowed field delimiters.

key

The value of the lookup key. Before using, it undergoes backslash interpretation and variable expansion.

kn

Number of the key field in file. Fields are numbered starting from 1.

vn

Number of the value field.

default

If supplied, this value is used as a replacement value, when the key was not found in file.

The map file consists of records, separated by newline characters (in other words, a record occupies one line). Each record consists of fields, separated by delimiters listed in delim argument. If delim contains a space character, then fields may be delimited by any amount of whitespace characters (spaces and/or tabulations). Otherwise, exactly one delimiter delimits fields.

Fields are numbered starting from 1.

The map action works as follows:

1. Variable expansion is performed on the key argument (see Variable expansion) and the resulting value is used as lookup key.
2. The file is scanned for a record whose knth field matches the lookup key.
3. If such a record is found, the value of its vnth field is assigned to the variable.
4. Otherwise, if default is supplied, it becomes the new value of the variable.
5. Otherwise, the variable remains unchanged.

For example, suppose that the file /etc/passwd.rush has the same syntax as the system passwd file (see Password File in passwd(5) man page). Then, the following statement will replace ‘$0’ with the value of ‘shell’ field, using the current user name as a key:

map [0] /etc/passwd.rush : ${user} 1 7

See also Interactive, for another example of using this statement.

4.4.4 Environment

The following actions modify the environment in which the program will be executed.

rule: clrenv

Clear the environment.

rule: keepenv list

Retain the names in list in the environment. This statement should be used in conjunction with clrenv.

Argument is a whitespace delimited list of variables to retain. Each element in the list can be either a variable name, or a shell-style globbing pattern, in which case all variables matching that pattern will be retained, or a variable name followed by an equals sign and a value, in which case it will be retained only if its actual value equals the supplied one. For example, to retain only variables with names beginning with ‘LC_’:

keepenv "LC_*"

rule: setenv name = value

Set the environment variable name. The value argument is subject to variable expansion (see Variable expansion) and backreference interpretation (see backreference).

For example, to modify the PATH value:

setenv PATH = "$PATH:/opt/bin"

rule: unsetenv list

Unset environment variables listed as arguments.

Argument is a whitespace delimited list of variables to retain. Each element in the list can be either a variable name, or a shell-style globbing pattern, in which case all variables matching that pattern will be unset, or a variable name followed by an equals sign and a value, in which case it will be unset only if its actual value equals the supplied one.

rule: evalenv string

Performs backslash interpretation, backreference interpretation and variable expansion on string and discards the result. This statement is similar to the shell’s colon statement. For example, the following statement will define the DEPTH variable and initialize it to 10, unless it is already defined:

evalenv ${DEPTH:=10}

4.4.5 Transformations

Transformations are special actions that modify entire command line or particular arguments from it (positional variables).

Statements that modify variable have been described in the previous section: these are set, insert, unset, remopt, delete and map statements. When set or map is applied to the ‘command’ variable, it modifies entire command line. When these statements are applied to an index (‘[n]’), they modify the corresponding positional variable (argument). This subsection discusses the implications of modifying these variable and illustrates them with some examples.

Positional variables and the $command request variable are mutually dependent. If the $command is modified, the word splitting is applied to it and resulting words are assigned to the positional variables. Similarly, any modifications to positional variables trigger rebuilding of the $command variable from the modified arguments. See Modifying variables, for more detail on it.

Let’s consider several examples.

1. Echo the command line

   rule
     set command = "/bin/echo $command"
   

2. Remove all occurrences of -r option and its arguments from the command line, and then adds its own -r option and replaces ‘svnserve’ with the full program file name.

   There are at least three different ways to do so.

   1. The recommended approach is to use the remopt and insert statements, as shown below:

      rule svn
        match $command ~ "^svnserve -t"
        set program = "/usr/bin/svnserve"
        remopt r:
        insert [1] = "-r"
        insert [2] = "/svnroot"
      

   2. The same can be achieved using regular expressions. This was the default in versions of rush prior to 2.0:

      rule svn
        match $command ~ "^svnserve -t"
        set command =~ "s/-r *[^ ]*//"
        set command =~ \
            "s|^svnserve |/usr/bin/svnserve -r /svnroot |"
      

      Notice the use of ‘|’ as a delimiter in s-command, in order to avoid escaping each ‘/’ in the pathname. Without it, the expression in the second set command will be

      "s/^svnserve /\\/usr\\/bin\\/svnserve -r \\/svnroot /"
      

   3. The same rule, rewritten using the single set statement:

      rule svn
        match $command ~ "^svnserve -t"
        set command =~ "s|-r *[^ ]*||;\
               s|^svnserve |/usr/bin/svnserve -r /svnroot |"
      

3. Override the executable program name.

   rule cvs
     match $command ~ "^cvs server"
     set [0] = /usr/bin/cvs
   

4.4.6 System Actions

System actions provide an interface to the operating system.

rule: umask mask

Set the umask. The mask must be an octal value not greater than ‘0777’. The default umask is ‘022’.

rule: newgrp group-id

rule: newgroup group-id

Change the current group ID to group-id, which is either a numeric value or a name of an existing group.

rule: chroot dir

Change the root directory to that specified in dir. This directory will be used for file names beginning with ‘/’. The argument is subject to tilde, variable, and backreference expansions. During tilde expansion, a tilde (‘~’) at the start of string is replaced with the absolute pathname of the user’s home directory. The two other expansions are described in Variable expansion, and backreference.

The directory dir must be properly set up to execute the commands. For example, the following rule defines execution of sftp-server in an environment chrooted to the user’s home directory:

rule sftp
  match $program ~ "^.*/sftp-server"
  set [0] = "bin/sftp-server"
  chroot "~"

For this to work, each user’s home must contain the directory bin with a copy of sftp-server in it, as well as all directories and files that are needed for executing it, in particular lib.

rule: chdir dir

Change to the directory dir. The argument is subject to tilde, variable (see Variable expansion), and backreference expansions (see backreference). If both chdir and chroot are specified, then chroot is applied first.

rule: limits res

Impose limits on system resources, as defined by res. The argument consists of commands, optionally separated by any amount of whitespace. A command is a single command letter followed by a number, that specifies the limit. The command letters are case-insensitive and coincide with those used by the shell ulimit utility:

Command	The limit it sets
A	max address space (KB)
C	max core file size (KB)
D	max data size (KB)
F	maximum file size (KB)
M	max locked-in-memory address space (KB)
N	max number of open files
R	max resident set size (KB)
S	max stack size (KB)
T	max CPU time (MIN)
U	max number of processes
L	max number of logins for this user (see below)
P	process priority -20..20 (negative = high priority)

For example:

limits T10 R20 U16 P20

If some limit cannot be set, execution of the rule aborts. In particular, the ‘L’ limit can be regarded as a condition, rather than an action. Setting limit Ln succeeds only if no more than n rush instances are simultaneously running for the same user. This can be used to limit the number of simultaneously open sessions.

The use of ‘L’ resource automatically enables forked mode. See Accounting and Forked Mode, for more information about it.

4.4.7 Fall-through

The fall-through statement is a special action that does not execute the requested command. When a matching fall-through rule is encountered, rush evaluates it and continues scanning its configuration for the next matching rule. Any modifications to the request found in the fall-through rule take effect immediately, which means that subsequent rules will see modified command line and environment. Execution of any other actions found in the fall-through rule is delayed until a usual rule is found.

A fall-through rule is declared using the following statement:

rule: fall-through

rule: fallthrough

Declare a fall-through rule.

Usually this statement is placed as the last statement in a rule, e.g.:

rule default
  umask 002
  clrenv
  keepenv HOME USERNAME PATH
  fall-through

Fall-through rules provide a way to set default values for subsequent rules. For example, any rules that follow the ‘default’ rule shown above, will inherit the umask and environment set there.

One can also use fall-through rules to “normalize” command lines. For example, consider this rule:

rule default
  set [0] =~ "s|.*/||"
  fall-through

It will remove all path components from the first command line argument. As a result, all subsequent rules may expect a bare binary name as the first argument.

Yet another common use for such rules is to enable accounting (see the next subsection), or set resource limits for the rest of rules:

rule default
  limit l1
  fall-through

4.4.8 Accounting and Forked Mode

GNU Rush is able to operate in two modes, which we call default and forked. When operating in the default mode, the process image of rush itself is overwritten by the command being executed. Thus, when it comes to launching the requested command, the running instance of rush ceases to exist.

There is also another operation mode, which we call forked mode. When running in this mode, rush executes the requested command in a subprocess, and remains in memory supervising its execution. Once the command terminates, rush exits.

One advantage of the forked mode is that it allows you to keep accounting, i.e. to note who is doing what and to keep a history of invocations. The accounting, in turn, can be used to limit simultaneous executions of commands (logins, in GNU Rush terminology), as requested by ‘L’ command to limit statement (see L limit).

The forked mode is enabled on a per-rule basis, for rules that contain either ‘L’ command in the limit statement, or ‘acct on’ command:

rule: acct bool

Turn accounting mode on or off, depending on bool. The argument can be one of the following: ‘yes’, ‘on’, ‘t’, ‘true’, or ‘1’, to enable accounting, and ‘no’, ‘off’, ‘nil’, ‘false’, ‘0’, to disable it.

Notice, that there is no need in explicit acct on command, if you use limit L.

The notion ‘rule contains’, used above, means that either the rule in question contains that statement, or inherits it from one of the fall-through rules (see Fall-through) that were matched before it. In fact, in most cases the accounting should affect all rules, therefore we suggest to enable it in a fall-through rule at the beginning of the configuration file, e.g.:

rule default
  acct on
  fall-through

If the need be, you can disable it for some of the subsequent rules by placing acct off in it. Notice, that this will disable accounting only, the forked mode will remain in action. To disable it as well and enforce default mode for a given rule, use the following statement:

rule: fork bool

Enable or disable forked mode. This statement is mainly designed as a way of disabling the forked mode for a given rule.

Once accounting is enabled, you can use the rushwho command to see the list of users presently running some commands (see Rushwho) and view the history of last accesses using rushlast command (see Rushlast).

4.4.9 Post-process Notification

Rush can be configured to send a notification over INET or UNIX sockets, after completing user request. It is done using the post-socket statement:

rule: post-socket url

Notify URL about completing the user request. This statement implies forked mode (see Accounting and Forked Mode).

Allowed formats for url are:

inet://hostname[:port]

Connect to remote host hostname using TCP/IP. Hostname is the host name or IP address of the remote machine. Optional port specifies the port number to connect to. It can be either a decimal port number or a service name from /etc/services. If port is absent, ‘tcpmux’ (port 1) is assumed.

unix://filename

local://filename

Connect to a UNIX socket filename.

For example:

rule default
  post-socket "inet://localhost"

The GNU Rush notification protocol is based on TCPMUX (RFC 1078).

After establishing connection, rush sends the rule tag followed by a CRLF pair. The rule tag acts as a service name. The remote party replies with a single character indicating positive (‘+’) or negative (‘-’) acknowledgment, optionally followed by a message of explanation, and terminated with a CRLF.

If positive acknowledgment is received, rush sends a single line, consisting of the user name and the executed command line, separated by a single space character. The line is terminated with a CRLF.

After sending this line, rush closes the connection.

The post-process notification feature can be used to schedule execution of some actions after certain rules.

See notification example, for an example of how to use this feature.

4.4.10 Exit rule

The exit rule does not execute any commands. Instead, it writes the supplied error message to the specified file descriptor and exits immediately. The exit rule is defined using the following statement:

rule: exit fd message

rule: exit message

Write textual message message to a file descriptor, given by the optional argument fd. If fd is absent, ‘2’ (standard error) is used.

The message argument can be either a quoted string, or an identifier.

If it is a quoted string, it is subject to backreference interpretation and variable expansion prior to being used.

For example (note the use of line continuation character):

exit "\
    \r\nYou are not allowed to execute that command.\r\n\
    \r\nIf you think this is wrong, ask <foo@bar.com> for assistance.\r\n"

If message is an identifier, it must be the name of a predefined error message (see Error Messages). The corresponding message text will be printed. For example:

  exit nologin-message

If the identifier does not match any predefined error message name, an error of type ‘config-error’ is signaled and rush exits.

Exit actions are useful for writing trap rules, i.e. the rules that are intended to trap incorrect or prohibited command lines and to return customized reply messages in such cases. Consider the following rule:

rule git
  match $program ~ "^git-.+" && $1 ~ "^/sources/[^ ]+\.git$"
  set command =~ "s|.*|/usr/bin/git-shell -c \"&\"|"

It allows the client to use only those Git repositories that are located under /sources directory⁴. If a user tries to access a repository outside this root, he will be returned a default error message, saying ‘You are not permitted to execute this command’ (see usage-error). You can, however, provide a more convenient message in this case. To do so, place the following after the ‘git’ rule:

rule git-trap
  match $command ~ "^git-.+"
  exit "fatal: Use of this repository is prohibited."

This rule will trap all git invocations that do not match the ‘git’ rule.

4.4.11 Interactive Access

Sometimes it may be necessary to allow some group of users limited access to interactive shells. GNU Rush contains provisions for such usage. When rush is invoked without -c it assumes interactive usage. In this case only rules explicitly marked as interactive are considered, the rest of rules is ignored.

rule: interactive bool

If bool is ‘true’, this statement marks the rule it appears in as interactive. This rule will match only if rush is invoked without command line arguments.

Unless command line transformations are applied, interactive rule finishes by executing /bin/sh. The first word in the command line (argv[0]) is normally set to the base name of the command being executed prefixed by a dash sign.

Consider the following example:

rule login
  interactive true
  group rshell
  map program /etc/rush.shell : ${user} 1 2
  set [0] = ${program} ~ "s|^.*/||;s,^,-r,"

rule nologin
  interactive true
  exit You don't have interactive access to this machine.

The ‘login’ rule will match interactive user requests if the user is a member of the group ‘rshell’. It uses /etc/rush.shell to select a shell to use for that user (see map). This map file consists of two fields, separated by a colon. If the shell is found, its base name, prefixed with ‘-r’, will be used as ‘argv[0]’ (this indicates a restricted login shell). Otherwise, the trap rule ‘nologin’ will be matched, which will output the given diagnostics message and terminate rush.

To test interactive access, use the -i option:

rush --test -i

4.4.12 Localization

GNU Rush is internationalized, which means that it is able to produce log and diagnostic messages in any language, if a corresponding translation file is provided. This file is called a localization or domain file. To find an appropriate localization file, rush uses the following parameters:

locale

Locale name is a string that describes the language, territory and optionally, the character set to use. It consists of the language (ISO 639) and country (ISO 3166) codes, separated by an underscore character, e.g. ‘en_US’ or ‘pl_PL’. If a character set is specified, its name follows the country code and is separated from it by a ‘@’ character.

There are two special locale names: ‘C’ or ‘POSIX’ mean to use the default POSIX locale, and ‘""’ (an empty string), means to use the value of the environment variable LC_ALL as the locale name.

locale_dir

Directory where localization files are located. If not specified, a predefined set of directories is searched for the matching file.

domain

Text domain defines the base name of the localization file.

Given these parameters, the name of the full pathname of the localization file is defined as:

locale_dir/locale/LC_MESSAGES/domain.mo

GNU Rush produces three kinds of messages:

diagnostics

These are diagnostics messages that GNU Rush produces to its log output (syslog, unless in test mode).

error messages

Messages sent to the remote party when rush is not able to execute the request (see Error Messages).

exit messages

These are messages sent to the remote party by exit rules (see Exit).

These messages use different domain names (and may use different locale directories). The diagnostics and error messages use textual domain ‘rush’. The corresponding locale directory is defined at compile time and defaults to prefix/share/locale, where prefix stands for the installation prefix, which is /usr/local, by default.

GNU Rush is shipped with several localization files, which are installed by default. As of version 2.2, these files cover the following languages: Chinese, Danish, Dutch, Finnish, French, Galician, German, Polish, Portuguese, Serbian, Spanish, Swedish, Ukrainian, and Vietnamese. If the localization you need is not in this list, visit http://translationproject.org/domain/rush.html. If it is not there either, consider writing it (see Translators in GNU gettext utilities, for a detailed instructions on how to do that).

Exit messages use custom domain files. It is the responsibility of the system administrator to provide and install such files.

4.4.12.1 Localization Directives

The following configuration directives control localization. They are available for use in rule statements:

rule: locale name

Sets the locale name. To specify empty locale, use ‘""’ as name (recall that empty locale name means to use the value of the environment variable LC_ALL as locale name).

rule: locale-dir name

Sets the name of the locale directory.

rule: text-domain name

Sets the textual domain name.

The following configuration fragment illustrates their use:

rule l10n
  locale "pl_PL"
  text-domain "rush-config"
  fall-through

Different users may have different localization preferences. See per-user l10n, for a description of how to implement this.

4.4.12.2 Writing Your Localization

You need to write a localization file for your configuration script if it implements exit rules (see Exit) and changes user locale (see locale).

Preparing a localization consists of three stages: extracting exit messages and forming a PO file, editing this file, compiling and installing it. The discussion below describes these stages in detail.

1. Creating a ‘po’ file.

   A PO (Portable Object) file is a plain text file, containing original messages and their translations for a particular language. See The Format of PO Files in GNU gettext utilities, for a description of its format.

   The script rush-po extracts translatable messages from the configuration file and produces a valid PO file. It takes the name of the rush configuration file as its argument and produces the PO file on the standard output, or in the file given with the -o (--output) option. E.g., to create a PO file from your configuration file, run:

   rush-po -o myconf.po /usr/local/etc/rush.rc
   

2. Editing the PO file

   Open the created PO file with your favorite editor and supply message translations after msgstr keywords. Although you can use any editor capable of handling plain text files, we recommend to use GNU Emacs, which provides a special po-mode. See PO Files and PO Mode Basics in GNU gettext utilities, for guidelines on editing PO files and using the po-mode.

3. Compiling the PO file

   When ready, the PO file needs be compiled into a MO (Message Object) file, which is directly readable by rush. This is done using msgfmt utility from GNU gettext:

     msgfmt -o myconf.mo myconf.po
   

   See msgfmt Invocation in GNU gettext utilities, for a detailed description of the msgfmt utility.

   After creating the MO file, copy it into appropriate directory. It is important that the installed MO file uses the naming scheme described in localization file naming.