{ "mode": "info", "parameter": "rush", "section": "", "url": "https://www.chedong.com/phpMan.php/info/rush/json", "generated": "2026-11-11T09:40:18Z", "sections": { "File: rush.info, Node: Top, Next: Intro, Up: (dir)": { "content": "", "subsections": [] }, "GNU Rush": { "content": "", "subsections": [] }, "This edition of the 'GNU Rush Manual', last updated 10 February 2022,": { "content": "documents GNU Rush Version 2.3.\n\n* Menu:\n\n* Intro::\n* Operation::\n* Quick Start::\n* Configuration File::\n* Default Configuration::\n* Usage Tips::\n* Test Mode::\n* Option Summary::\n* Rushwho:: The 'rushwho' utility.\n* Rushlast:: The 'rushlast' utility.\n* Accounting Database::\n* Reporting Bugs:: How to Report a Bug.\n", "subsections": [] }, "Appendices": { "content": "* Time and Date Formats::\n* Copying This Manual:: The GNU Free Documentation License.\n* Concept Index:: Index of Concepts.\n\n-- The Detailed Node Listing --\n", "subsections": [] }, "Configuration File": { "content": "* Lexical Structure::\n* Syntax::\n* Global::\n* Rule::\n* Include::\n", "subsections": [] }, "The 'global' statement": { "content": "* Expansion control::\n* Debugging::\n* sleep-time::\n* Error Messages::\n* regexp::\n* include-security::\n* Accounting control::\n", "subsections": [] }, "Rule": { "content": "The tag of the rule he is served under (*note tag: Rule.).\n", "subsections": [] }, "The Request": { "content": "* Positional variables::\n* Request variables::\n* Environment variables::\n* User-defined variables::\n* Variable expansion::\n", "subsections": [] }, "Matching Conditions": { "content": "* Comparisons::\n* Membership operators::\n* File system tests::\n* Boolean expressions::\n", "subsections": [] }, "Modifying variables": { "content": "* set:: Set variable.\n* insert:: Insert positional arguments.\n* unset:: Unset variable.\n* remopt:: Remove options.\n* delete:: Delete arguments.\n* map:: Use file lookup to modify variable.\n", "subsections": [] }, "Localization": { "content": "* Localization Directives::\n* Writing Your Localization::\n", "subsections": [] }, "Usage Tips": { "content": "* scp::\n* rsync::\n* sftp::\n* cvs::\n* svn::\n* git::\n* notification example::\n\nTest Mode\n\n* dump mode::\n\nThe 'rushwho' utility.\n\n* Rushwho Options::\n* Formats::\n\nThe 'rushlast' utility.\n\n* Rushlast Options::\n", "subsections": [] }, "Accounting Database": { "content": "* wtmp:: The Structure of 'wtmp' File.\n* utmp:: The Structure of 'wtmp' File.\n\n", "subsections": [] }, "File: rush.info, Node: Intro, Next: Operation, Prev: Top, Up: Top": { "content": "", "subsections": [] }, "1 Introduction": { "content": "GNU Rush is a Restricted User Shell, designed for sites that provide\nlimited remote access to their resources, such as svn or git\nrepositories, scp, or the like. Using a sophisticated configuration\nfile, GNU Rush gives you complete control over the command lines that\nusers execute, as well as over the usage of system resources, such as\nvirtual memory, CPU time, etc.\n", "subsections": [] }, "File: rush.info, Node: Operation, Next: Quick Start, Prev: Intro, Up: Top": { "content": "", "subsections": [] }, "2 Operation": { "content": "GNU Rush is usually installed as a user shell. When a user connects to\nthe server (e.g. by using using SSH protocol), the shell binary,\n'rush', is executed. GNU Rush must be called with exactly two\narguments: the '-c' command line option and a command line to be\nexecuted on the host machine(1). If wrong arguments are supplied, the\nshell aborts.\n\nThe third argument to 'rush' supplies a command line to be executed.", "subsections": [] }, "That command line, shell environment for its execution and the password": { "content": "database entry for the user who executes 'rush' are said to form a\n\"request\".\n\nAfter startup, 'rush' reads a set of \"rules\" from its configuration\nfile. Each rule consists of matching conditions and actions.\n\"Conditions\" decide whether the request matches the rule. They can\ninclude regular expression matching against entire command line or\nparticular words thereof, comparisons of user name or group,, etc. If\nall conditions match the request, actions are executed. \"Actions\" can\ninstruct 'rush' to:\n\n* Modify the command line;\n* Impose resource limits;\n* Set umask;\n* Change current working directory;\n* Modify the execution environment;\n* Run command in a special root directory ('chroot').\n\nFinally, after all actions have been completed successfully, 'rush'\nruns the requested command. Notice, that by that time the resulting\ncommand line is not necessarily the same as the original one supplied to\n'rush' with the '-c' option.\n\nA special kind of rules, called \"fall-through\" ones, is provided.", "subsections": [] }, "Fall-through rules differ from other rules in that they do not execute": { "content": "the command. After all actions in a fall-through rule have been\nexecuted, GNU Rush continues to search for another matching rule in its\nconfiguration and applies it, if found. Fall-through rules are useful\nto set default values for subsequent rules.\n\n---------- Footnotes ----------\n\n(1) Starting from version 1.6, it is possible to use GNU Rush for\ninteractive shell sessions. *Note Interactive::, for more information\nabout it.\n", "subsections": [] }, "File: rush.info, Node: Quick Start, Next: Configuration File, Prev: Operation, Up: Top": { "content": "", "subsections": [] }, "3 Quick Start": { "content": "", "subsections": [] }, "To give you the feel of GNU Rush possibilities, let's consider the": { "content": "following configuration file rule:\n\nrush 2.0\n\nrule sftp\n# Matching condition\nmatch $uid >= 100 && $command ~ \"^.*/sftp-server\"\n# Actions:\nset [0] = \"bin/sftp-server\"\numask 002\nchroot \"~\"\nchdir \"/\"\n\nThe first clause defines the version of the syntax this configuration\nuses. Each configuration must begin with this statement.\n\nNext clause, 'rule', defines a new rule. Its argument serves as a\nrule tag and is used for diagnostic messages and in accounting.\n\nLines beginning with '#' are comments, they are intended for a human\nreader and are ignored by 'rush'.\n\nThe 'match' statement, defines condition that must be met for this\nrule to become active. In this example it requests that the UID of the\nrequesting user be greater than or equal to 100, and the command line\nbegin with '/sftp-server', optionally preceded by arbitrary directory\ncomponents.\n\nSubsequent clauses define actions associated with this rule.\n\nThe 'set' clause contains instructions on how to modify the first\nargument of the command line. Argument indices start at 0, so '[0]'\nrefers to the command name. The expression in our example instructs GNU\nRush to replace it with 'bin/sftp-server'.\n\nThe 'umask' clause sets the file creation mask.\n\nThe 'chroot' clause instructs GNU Rush to chroot to the user home\ndirectory before executing the command.\n\nFinally, the 'chdir' statement sets the directory to change to after\ninstalling the chroot.\n", "subsections": [] }, "File: rush.info, Node: Configuration File, Next: Default Configuration, Prev: Quick Start, Up: Top": { "content": "", "subsections": [] }, "4 Configuration File": { "content": "", "subsections": [] }, "The configuration file 'rush.rc' is located in '/usr/local/etc' by": { "content": "default.(1).\n\nThe configuration file is read and parsed right after start up. Any\nerrors occurred in parsing are reported using 'syslog' facility\n'authpriv' and priority 'notice'. When run in 'test' mode, all\ndiagnostics is displayed on the standard error output. *Note Test", "subsections": [] }, "Mode::, for a detailed description of ways to debug and test your": { "content": "configurations.\n\nBefore parsing, 'rush' checks the ownership and permissions of the\nconfiguration file for potential security breaches. The configuration\nfile is considered unsafe if any of the following conditions are met:\n\n1. It is not owned by root.\n2. It is group writable.\n3. It is world writable.\n4. It resides in a group writable directory.\n5. It resides in a world writable directory.\n6. It is a symbolic link to a file residing in a group or world\nwritable directory.\n\nIf the file is considered unsafe, 'rush' rejects it and aborts\nexecution.\n\nAny of these tests can be disabled using the '--security-check'\noption (*note --security-check::).\n\nAs of version 2.3, 'rush' supports two distinct configuration file\nformats.\n\nThe \"legacy\" configuration format is the one used in rush versions up\nto 1.9. It is still supported to facilitate transition of existing\ninstallations to the new syntax. Its support will eventually be removed\nin future versions, so the users are encouraged to switch to the new\nsyntax as soon as possible. The legacy syntax is described in detail in\n.\n\nThis manual describes new configuration file format.\n\n* Menu:\n\n* Lexical Structure::\n* Syntax::\n* Global::\n* Rule::\n* Include::\n\n---------- Footnotes ----------\n\n(1) The exact location of the configuration file is defined when\nconfiguring the package. See the file 'INSTALL' in the GNU Rush source\ndirectory for more information\n", "subsections": [] }, "File: rush.info, Node: Lexical Structure, Next: Syntax, Up: Configuration File": { "content": "", "subsections": [ { "name": "4.1 Lexical Structure of the Configuration File", "content": "" } ] }, "Configuration file consists of tokens separated by arbitrary amount of": { "content": "whitespace characters: horizontal spaces and tabs. Except when enclosed\nin double quotes or preceded by a dollar sign, the '#' character\nintroduces an inline comment: the character itself and any material that\nfollows it up to the end of the physical line is ignored. Comments are\ntreated as newlines.\n\nThe following classes of tokens are recognized.\n\n\"Newlines\"\nA newline character (ASCII 10) terminates a statement. If newline\nis immediately preceded by a backslash, both characters are removed\nand the following line is treated as a continuation of the current\nline. This allows for splitting exceedingly long statements over\nseveral physical lines.\n\n\"Identifiers\"\nIdentifiers begin with a letter and consist of letters, digits,\nunderscores and dashes. They serve as keywords and variable names.\n\n\"Decimal numbers\"\nA sequence of decimal digits, optionally preceded by a minus or\nplus sign.\n\n\"Unquoted strings\"\nAn unquoted string is any contiguous sequence of any characters,\nexcept newlines, whitespace and the following special characters:\n'\\', '\"', '!', '=', '<', '>', '(', ')', '{', '}', '[', ']', '$',\n'%', '&', '|', '~', '#'.\n\n\"Quoted strings\"\nA quoted string is a sequence of characters enclosed in\ndouble-quotes. Quoted strings are subject to backslash\ninterpretation, backreference interpretation and variable\nexpansion.\n\nDuring \"backslash interpretation\", the \"escape sequences\" are\nrecognized and replaced as per table below:\n\nSequence Replaced with\n\\a Audible bell character (ASCII 7)\n\\b Backspace character (ASCII 8)\n\\f Form-feed character (ASCII 12)\n\\n Newline character (ASCII 10)\n\\r Carriage return character (ASCII\n13)\n\\t Horizontal tabulation character\n(ASCII 9)\n\\v Vertical tabulation character\n(ASCII 11)\n\\\\ Single backslash character\n\\\" Double-quote\n\\% Percent character\n\nTable 4.1: Backslash escapes\n\nA backslash immediately followed by newline character is removed.\nA backslash followed by any other character except as listed above\nis retained along with the character.\n\nDuring \"backreference interpretation\", references to parenthesized\ngroups in regular expression are replaced with the actual content\nof the corresponding group in the most recently matched string. A\nreference is '%{N}' where N is a decimal number. If N is one\ndigit, curly braces can be omitted: '%N'. If the '%' character\nresults from previous backslash interpretation, no backreference\ninterpretation occurs.\n\nStrings used in the left-hand side of a comparison expression are\nsubject to variable expansion. This is discussed in detail in\n*note Variable expansion::.\n\n\"Variable references\"\nVariable references consist of a '$' sign, followed by the\npositional argument number or variable name, optionally enclosed in\ncurly braces. Positional arguments greater than 9 must be enclosed\nin curly braces. The variable name must follow the rules for valid\nidentifiers: it must begin with a letter and consist of letters,\ndigits and underscores. Variable name in curly braces can be\nfollowed by '-', '=', '?', or '+', optionally preceded by ':' as\nsummarized in the table below:\n\nReference Meaning\n${VAR:-WORD} Use Default Values\n${VAR:=WORD} Assign Default Values\n${VAR:?WORD} Display Error if Null or Unset\n${VAR:+WORD} Use Alternate Value\n\nTable 4.2: Variable reference\n\nWhere WORD stands for any valid token as described in this section.\n*Note Variable expansion::, for a detailed discussion of these\nforms and their meaning.\n\n\"Comparison and boolean operators\"\nThese are:\n\n'&&' Boolean \"and\"\n'||' Boolean \"or\"\n'!' Boolean negation\n'==' Equality (string or numeric)\n'!=' Inequality (string or numeric)\n'<' Less than\n'<=' Less than or equal to\n'>' Greater than\n'>=' Greater than or equal to\n'~' Regexp matching\n'!~' Negated regexp matching\n'in' Membership in set of strings\n'group' Membership in UNIX group\n'=' Assignment\n'=~' Regular expression substitution\n\nTable 4.3: Operators\n\n*Note Matching Conditions::, for a detailed discussion.\n", "subsections": [] }, "File: rush.info, Node: Syntax, Next: Global, Prev: Lexical Structure, Up: Configuration File": { "content": "", "subsections": [ { "name": "4.2 Syntax", "content": "The 'rush' configuration consists of \"statements\".\n\nA \"statement\" consists of a keyword and optional arguments, separated\nby any amount of whitespace. Each statement occupies one line in the\nconfiguration file and is terminated by a newline character. Extremely\nlong statements may be split across several physical lines by ending\neach line except the last with a backslash followed by a newline.\n\nStatements may be separated by any amount of empty lines or comments.\n\nThe first statement in a configuration file indicates the syntax\nversion. It has the following form:\n\nrush 2.0\n\nThis statement is mandatory. In its absence, the file will be\ntreated as a legacy configuration file(1). To avoid confusion, a notice\nmessage to that effect will be printed.\n\nStatements that follow form logical groups. Each group begins with a\n'rule' or 'global' statement.\n\nThe 'global' statement introduces global settings. It affects all\nstatements that follow it.\n\nThe 'rule' statement introduces a single 'rush' rule, that defines\nhow to process a particular command.\n\nThese statements are described in the sections that follow.\n\n---------- Footnotes ----------\n\n(1) For the discussion of the legacy syntax, please refer to\n.\n" } ] }, "File: rush.info, Node: Global, Next: Rule, Prev: Syntax, Up: Configuration File": { "content": "", "subsections": [ { "name": "4.3 The 'global' statement", "content": "The 'global' statement defines global settings. The syntax is:\n\nglobal\nSTMT1\nSTMT2\n...\n\nwhere dots represent any number of statements. The following\nsubsections discuss the statements that can be used within a 'global'\nblock.\n\n* Menu:\n\n* Expansion control::\n* Debugging::\n* sleep-time::\n* Error Messages::\n* regexp::\n* include-security::\n* Accounting control::\n" } ] }, "File: rush.info, Node: Expansion control, Next: Debugging, Up: Global": { "content": "", "subsections": [] }, "The following statement controls the behavior of 'rush' when an": { "content": "undefined variable is expanded (*note Variable expansion::).\n\n-- global: expand-undefined BOOL\nIf BOOL is 'true', expand undefined variables to empty value. If\nit is 'false' (the default), issue an error and abort.\n\nThe following values can be used as synonyms for 'true': 'yes',\n'on', 't', '1'.\n\nThe following values can be used as synonyms for 'false': 'no',\n'off', 'nil', '0'.\n\n*Note handling of undefined variables::, for a detailed discussion of\nhow 'rush' processes undefined variables and for the recommended\ntechniques of handling them.\n", "subsections": [] }, "File: rush.info, Node: Debugging, Next: sleep-time, Prev: Expansion control, Up: Global": { "content": "The 'debug' global statement sets the \"debugging level\" - an integer\nvalue that controls the verbosity of 'rush':\n\n-- global: debug NUM\nSet debugging level to NUM.\n\nThe greater NUM is, the more verbose is the logging. The debugging\ninformation is reported via 'syslog' at facility 'authpriv', priority\n'debug'. As of version 2.3, the following debugging levels are\nsupported:\n\n1\nA minimum debugging level, and the only one whose messages are\nlogged using the priority 'notice'. At this level, 'rush' only\nlogs requests and rules selected to handle them. For example:\n\nrush[16821]: Serving request \"/usr/libexec/sftp-server\"\nfor sergiusz by rule sftp-savane\n\n2\nList all actions executed when serving requests.\n\n3\nWhen parsing a legacy configuration file, verbosely describe\nparsing process.\n\nMore debugging levels may be implemented in future.\n", "subsections": [] }, "File: rush.info, Node: sleep-time, Next: Error Messages, Prev: Debugging, Up: Global": { "content": "-- global: sleep-time NUM\nSet the time to sleep before exiting on error, in seconds. This\nstatement is intended as a measure against brute-force attacks.\nDefault sleep time is 5 seconds.\n", "subsections": [] }, "File: rush.info, Node: Error Messages, Next: regexp, Prev: sleep-time, Up: Global": { "content": "-- global: message CLASS TEXT\nDefine a textual message which is returned to the remote party if\nan error of the given CLASS occurs.\n\nValid values for CLASS are:\n\nusage-error\nThis error is reported when 'rush' has been invoked improperly.\nThe default text is:\n\nYou are not permitted to execute this command.\n\nnologin-error\nDefine a textual message which is returned to the remote user if\nthere is no such user name in the password database.\n\nDefault is:\n\nYou do not have interactive login access to this machine.\n\nconfig-error\nDefine a textual message which is returned to the remote party if\nthe 'rush' configuration file contains errors.\n\nDefault is:\n\nLocal configuration error occurred.\n\nsystem-error\nDefine a textual message which is returned to the remote party if a\nsystem error occurs.\n\nDefault message is:\n\nA system error occurred while attempting to execute command.\n", "subsections": [] }, "File: rush.info, Node: regexp, Next: include-security, Prev: Error Messages, Up: Global": { "content": "", "subsections": [] }, "The 'regexp' statement configures the flavor of regular expressions for": { "content": "use by subsequent 'match', 'set', and 'insert' statements.\n\n-- global: regexp FLAGS ...\nConfigure the type of regular expressions.\n\nEach FLAG is a word specifying some regular expression feature. It\ncan be preceded by '+' to enable this feature (this is the default), or\nby '-' to disable it. Valid flags are:\n\n'extended'\nUse POSIX Extended Regular Expression syntax when interpreting\nregex. This is the default.\n\n'basic'\nUse basic regular expressions. Equivalent to '-extended'.\n\n'icase'\n'ignore-case'\nDo not differentiate case. Subsequent regex matches will be case\ninsensitive.\n\nFor example, the following statement enables POSIX extended, case\ninsensitive matching:\n\nglobal\nregex +extended +icase\n", "subsections": [] }, "File: rush.info, Node: include-security, Next: Accounting control, Prev: regexp, Up: Global": { "content": "", "subsections": [] }, "Additional configuration can be included to the main configuration file": { "content": "using the 'include' statement (*note Include::). Before inclusion, a\nnumber of checks is performed on the file to ensure it is safe to rely\non it. These checks are configured using the following statement:\n\n-- global: include-security LIST\nConfigure the security checks for include files. This statement\ntakes a list of arguments, separated by white space. The following\narguments are recognized:\n\nall\nEnable all checks.\n\nowner\nThe file is not owned by root.\n\niwgrp\ngroupwritablefile\nThe file is group writable.\n\niwoth\nworldwritablefile\nThe file is world writable.\n\ndiriwgrp\ngroupwritabledir\nThe file resides in a group writable directory.\n\ndiriwoth\nworldwritabledir\nThe file resides in a world writable directory.\n\nlink\nThe file is a symbolic link to a file residing in a group or\nworld writable directory.\n\nEach of the above keywords may be prefixed by 'no', which reverses\nits meaning. The special keyword 'none' disables all checks. Each\nkeyword adds or removes a particular test to the existing check list,\nwhich is initialized as described in *note security checks::. Thus, the\nfollowing statement results in all checks, except for the file\nownership:\n\nglobal\ninclude-security noowner\n\nIn the example below, the check list is first cleared by using the\n'none' statement, and then a set of checks is added to it:\n\nglobal\ninclude-security none owner iwoth iwgrp\n", "subsections": [] }, "File: rush.info, Node: Accounting control, Prev: include-security, Up: Global": { "content": "", "subsections": [] }, "The following global statements control file mode and permissions of the": { "content": "\"accounting database files\". For a detailed description of this\nfeature, *Note Accounting Database::.\n\n-- global: acct-umask MASK\nSet umask used when accessing accounting database files. Default\nvalue is '022'.\n\n-- global: acct-dir-mode MODE\nSet mode bits for the accounting directory. The MODE argument is\nthe mode in octal.\n\n-- global: acct-file-mode MODE\nSet mode bits for the 'wtmp' and 'utmp' files.\n", "subsections": [] }, "File: rush.info, Node: Rule, Next: Include, Prev: Global, Up: Configuration File": { "content": "", "subsections": [ { "name": "4.4 Rule", "content": "The 'rule' statement configures a GNU 'rush' rule. This is a \"block\"\nstatement, which means that all statements located between it and the\nnext 'rule' statement (or end of file, whichever occurs first) modify\nthe definition of that rule.\n\nThe syntax of the 'rule' statement is:\n\n-- Configuration: rule TAG\n\nThe TAG argument is optional. If it is given, it supplies a \"tag\"\nfor the rule, i.e. a (presumably unique) identifier, which is used to\nlabel this rule. 'Rush' uses this tag in its diagnostic messages. For\nrules without explicit TAG, 'Rush' supplies a default tag, which is\nconstructed by concatenating '#' character and the ordinal number of\nrule in the configuration file, in decimal notation. Rule numbering\nstarts from '1'.\n\nEach rule group can contain a number of statements that control what\nkind of requests match that rule and what actions are taken when the\nrule is matched. Arguments to this statements can refer to command line\narguments and other parts of the request.\n\n* Menu:\n\n* Request::\n* Matching Conditions::\n* Modifying variables::\n* Environment::\n* Transformations::\n* System Actions::\n* Fall-through::\n* Accounting and Forked Mode::\n* Notification::\n* Exit::\n* Interactive::\n* Localization::\n" } ] }, "File: rush.info, Node: Request, Next: Matching Conditions, Up: Rule": { "content": "", "subsections": [] }, "User request consists of the user 'passwd' entry, the command line": { "content": "supplied to 'rush', and environment variables. The request is analyzed\nand can be eventually modified by rules in 'rush' configuration file.\nRules access parts of the request using \"variables\".\n\nThere are four classes of variables. All of them share the same\nnamespace and are accessed using the same syntax.\n\n* Menu:\n\n* Positional variables::\n* Request variables::\n* Environment variables::\n* User-defined variables::\n* Variable expansion::\n", "subsections": [] }, "File: rush.info, Node: Positional variables, Next: Request variables, Up: Request": { "content": "4.4.1.1 Positional variables\n............................\n", "subsections": [] }, "Rush performs word splitting using the same rules as 'sh'. Statements": { "content": "in the configuration file refer to command line arguments (\"words\") by\ntheir \"index\", using \"positional variables\". A positional variable can\nhave the following forms:\n\n$N\n${N}\n\nwhere N is the variable index. The form with curly braces must be used\nif N is negative (see below) or greater than 9.\n\nArguments are numbered from '0'. The name of the command is argument\n'$0'. Consider, for example, the following command line:\n\n/bin/scp -t /upload\n\nWord splitting phase results in three positional variables being\ndefined:\n\n$0 /bin/scp\n$1 -t\n$2 /upload\n\nThese values can also be referred to using negative indexes. They\nrefer to words in the reverse order, as illustrated in the following\ntable (notice the use of curly braces):\n\n${-3} /bin/scp\n${-2} -t\n${-1} /upload\n\nNotice also, that negative indexes are 1-based.\n\nOne final note about the '$0' variable. Immediately after word\nsplitting it refers to both the executable program name and the 0th\nargument that will be passed to that program ('argv[0]'). Most of the\ntime the two values coincide. However, the rule can modify either\nvalue, so that they become different. Whether modified or not, the\nactual name of the program to be run is kept in the request variable\n'$program' (see the following section).\n", "subsections": [] }, "File: rush.info, Node: Request variables, Next: Environment variables, Prev: Positional variables, Up: Request": { "content": "4.4.1.2 Request variables\n.........................\n", "subsections": [] }, "The following variables can be used to refer to various parts of the": { "content": "user request:\n\n$user User name\n$group Name of the user's principal group\n$uid UID\n$gid GID\n$home User's home directory\n$gecos User's GECOS field\n$program Executable program name\n$command Entire command line\n$# Number of arguments in '$command'\n", "subsections": [] }, "File: rush.info, Node: Environment variables, Next: User-defined variables, Prev: Request variables, Up: Request": { "content": "4.4.1.3 Environment variables\n.............................\n", "subsections": [] }, "Environment variables are accessed using the same syntax as the rest of": { "content": "the variables. Rules can modify them using the 'setenv', 'clrenv' and\n'keepenv' statements (*note Environment::).\n", "subsections": [] }, "File: rush.info, Node: User-defined variables, Next: Variable expansion, Prev: Environment variables, Up: Request": { "content": "4.4.1.4 User-defined variables\n..............................\n", "subsections": [] }, "In addition to the built-in variables, arbitrary variables can be": { "content": "defined and used in the configuration file. These \"user-defined\"\nvariables are defined using the 'set' statement (*note set::) and are\nnormally used to pass information between rules. They are invisible to\nwhatever command 'rush' executes as the final result of processing.\n", "subsections": [] }, "File: rush.info, Node: Variable expansion, Prev: User-defined variables, Up: Request": { "content": "4.4.1.5 Variable Expansion\n..........................\n", "subsections": [] }, "Most statements in the configuration file undergo variable expansion": { "content": "prior to their use. During variable expansion, references to variables\nin the string are replaced with their actual values. A variable\nreference has two basic forms:\n\n$V\n${V}\n\nwhere V is either the name of the variable (request, environment, or\nuser-defined), or the index of the positional variable. The notation in\ncurly braces serves several purposes. First, it is obligatory if V is\nan index of the positional variable that is negative or greater than 9.", "subsections": [] }, "Secondly, it should be used if the variable reference is immediately": { "content": "followed by an alphanumeric symbol, which will otherwise be considered\npart of it (as in '${home}dir'). Finally, this form allows for\nspecifying the action to take if the variable is undefined or expands to\nan empty value.\n\nThe following special forms are recognized:\n\n${VARIABLE:-WORD}\n\"Use Default Values\". If VARIABLE is unset or null, the expansion\nof WORD is substituted. Otherwise, the value of VARIABLE is\nsubstituted.\n\n${VARIABLE:=WORD}\n\"Assign Default Values\". If VARIABLE is unset or null, the\nexpansion of WORD is assigned to variable. The value of VARIABLE\nis then substituted.\n\n${VARIABLE:?WORD}\n\"Display Error if Null or Unset\". If VARIABLE is null or unset,\nthe expansion of WORD (or a message to that effect if WORD is not\npresent) is output to the current logging channel. Otherwise, the\nvalue of VARIABLE is substituted.\n\n${VARIABLE:+WORD}\n\"Use Alternate Value\". If VARIABLE is null or unset, nothing is\nsubstituted, otherwise the expansion of WORD is substituted.\n\nThese constructs test for a variable that is unset or null. Omitting\nthe colon results in a test only for a variable that is unset.\n\nWhen expanding a variable reference, the variable name is first\nlooked among the request variables. If it is not found, it is looked up\nin the user-defined variable list. If it is not there, the look up in\nthe environment is attempted.\n\nIf the variable name is not found in any of these lists, the default\n'rush' behavior is to report the error of 'config-error' class (*note", "subsections": [] }, "Error Messages::) and exit. To gracefully handle such cases, use the": { "content": "\"default value construct\", defined above. For example, the following\nstatement safely appends the string '/opt/man' to the value of the\n'MANPATH' environment variable:\n\nsetenv MANPATH = \"${MANPATH:-\"\"}${MANPATH:+:}/opt/man\"\n\nThe '${MANPATH:-\"\"}' reference ensures no error is reported if the\nvariable is undefined. The '${MANPATH:+:}' reference appends a\nsemicolon to the value, if the variable is defined. Finally the string\n'/opt/man' is appended to the resulting value.\n\nAnother way to gracefully handle undefined variables, is to use the\n'expand-undefined' global setting. If you place the following statement\nat the beginning of your configuration file, any undefined variable will\nbe silently expanded to empty string:\n\nglobal\nexpand-undefined true\n\nThis statement affects variable expansion in statements that follow\nit in the configuration file. So you can place it in some point after\nwhich this behavior is needed, and then disable it where it is no longer\ndesired, by using the following global statement:\n\nglobal\nexpand-undefined false\n", "subsections": [] }, "File: rush.info, Node: Matching Conditions, Next: Modifying variables, Prev: Request, Up: Rule": { "content": "-- rule: match EXPR\nThe 'match' statement defines conditions that decide whether the\nrule matches the particular request. Its argument is a simple\nexpression or a boolean expression involving several simple\nexpressions.\n\nA \"simple expression\" is either a comparison or membership test.\n\n* Menu:\n\n* Comparisons::\n* Membership operators::\n* File system tests::\n* Boolean expressions::\n", "subsections": [] }, "File: rush.info, Node: Comparisons, Next: Membership operators, Up: Matching Conditions": { "content": "4.4.2.1 Comparisons\n...................\n\nA \"comparison expression\" is:\n\nLHS OP RHS\n\nhere, LHS (\"left-hand side\") is a string (quoted or unquoted), or a\nvariable reference (*note Lexical Structure::), RHS (\"right-hand side\")\nis a string or number, and OP is one of the following binary operators:\n\n'==' Equality (string or numeric)\n'!=' Inequality (string or numeric)\n'<' Less than\n'<=' Less than or equal to\n'>' Greater than\n'>=' Greater than or equal to\n'~' Regexp matching\n'!~' Negated regexp matching\n", "subsections": [] }, "Table 4.4: Comparison Operators": { "content": "Prior to evaluating simple expression, its left-hand side undergoes\nvariable expansion and backreference interpretation. In contrast, the\nright-hand side is always treated verbatim.\n\nFor example the following rule will match any request with 2 or more\narguments (recall, that the command name itself is counted as one of the\narguments):\n\nrule\nmatch $# >= 2\n\nThe '==' and '!=' can operate both on strings and on numbers. When\napplied to strings the '==' means byte-to-byte equality, e.g.\n\nmatch $0 == \"/bin/ls\"\n\nwill match requests with '/bin/ls' as the command name.\n\nThe '~' and '!~' operators implement \"regular expression matching\".\n\nThe expression 'LHS ~ RX' yields 'true' if LHS matches regular\nexpression RX. E.g.\n\nmatch $command ~ \"^scp (-v )?-t /incoming/(alpha|ftp)\"\n\nThe '!~' evaluates to 'true' if LHS does not match the regular\nexpression in the RHS.\n\nIf the regular expression contains parenthesized groups, subsequent\ncommands can refer to the strings that matched the groups using the\n\"backreference notation\" '%N', where N is 1-based index ordinal number\nof the group in the regular expression (*note backreference::). The\nreference '%0' expands to the entire matched string. For example:\n\nrule chdir\nmatch $command \"^cd (.+) && (.+)\"\nchdir %1\nset command = %2\nfall-through\n\nIt splits the compound command into the working directory and the\ncommand itself. Then it remembers the name of the working directory\n(first parenthesized group - '%1') for changing to it later (*note\nchdir::) and resets the command line to the part of the string that\nfollows the '&&' token. Finally, it passes control to another rules\n(*note Fall-through::).\n", "subsections": [] }, "File: rush.info, Node: Membership operators, Next: File system tests, Prev: Comparisons, Up: Matching Conditions": { "content": "4.4.2.2 Membership operators\n............................\n", "subsections": [] }, "Membership operators check if their argument is a member of some set of": { "content": "values. There are two such operators.\n\nLHS in ( ARGS )\n\nThe 'in' operator evaluates to 'true' if LHS is listed in ARGS, which\nis a whitespace-separated list of strings. For example:\n\nmatch $0 in (\"scp\" \"rsync\")\n\nThe 'group' operator evaluates to 'true' if the requesting user is a\nmember of at least one group listed in its right-hand side. It can have\ntwo forms:\n\n'group GRP'\nEvaluate to 'true' if the user is a member of the group GRP. The\ngroup can be given either by its name or GID.\n\n'group ( LIST )'\nEvaluate to 'true' if the user is a member of one of the groups in\nwhitespace delimited LIST. Members of LIST are group names or\nGIDs.\n", "subsections": [] }, "File: rush.info, Node: File system tests, Next: Boolean expressions, Prev: Membership operators, Up: Matching Conditions": { "content": "4.4.2.3 File system tests\n.........................\n", "subsections": [] }, "File system tests check file types and ownership. They are similar to": { "content": "options to 'test' shell command:\n\n'-b FILE'\nFILE exists and is block special\n\n'-c FILE'\nFILE exists and is character special\n\n'-d FILE'\nFILE exists and is a directory\n\n'-e FILE'\nFILE exists\n\n'-f FILE'\nFILE exists and is a regular file\n\n'-g FILE'\nFILE exists and is set-group-ID\n\n'-G FILE'\nFILE exists and is owned by the primary group of the current user.\n\n'-h FILE'\n'-L FILE'\nFILE exists and is a symbolic link\n\n'-k FILE'\nFILE exists and has its sticky bit set\n\n'-L FILE'\nFILE exists and is a symbolic link (same as -h)\n\n'-O FILE'\nFILE exists and is owned by the current user\n\n'-p FILE'\nFILE exists and is a named pipe\n\n'-r FILE'\nFILE exists and read permission is granted\n\n'-s FILE'\nFILE exists and has a size greater than zero\n\n'-S FILE'\nFILE exists and is a socket\n\n'-u FILE'\nFILE exists and its set-user-ID bit is set\n\n'-w FILE'\nFILE exists and write permission is granted\n\n'-x FILE'\nFILE exists and execute (or search) permission is granted\n", "subsections": [] }, "File: rush.info, Node: Boolean expressions, Prev: File system tests, Up: Matching Conditions": { "content": "4.4.2.4 Boolean expressions\n...........................\n", "subsections": [] }, "Simple expressions can be combined into complex conditions using boolean": { "content": "operators:\n\n'||' Disjunction (\"or\")\n'&&' Conjunction (\"and\")\n'!' Negation\n", "subsections": [] }, "Table 4.5: Boolean Operators": { "content": "Arguments to these operators can be either simple expressions or\nanother boolean expressions. The operators in the table above are\nordered by their precedence. As in most programming languages,\nparentheses can be used to enforce the desired order of evaluation.\n\nBoth binary operators implement shortcut evaluation.\n\nFor example, the following rule will match if the command name\ncontains 'git-receive-pack' or 'git-upload-pack' and either the UID is\n100 or the user is a member of the group 'git':\n\nrule\nmatch $0 ~ \"git-(receive|upload)-pack\" && \\\n($uid == 100 || group \"git\")\n", "subsections": [] }, "Notice the use of parentheses to enforce proper evaluation order. The": { "content": "'&&' operator has higher priority than '||'. Without parentheses the\nrule would match if either the command name matched the regexp and the\nuser ID was 100, or if the user was a member of the 'git' group, no\nmatter what command was issued.\n", "subsections": [] }, "File: rush.info, Node: Modifying variables, Next: Environment, Prev: Matching Conditions, Up: Rule": { "content": "", "subsections": [] }, "Rules can change or unset variables. Two separate groups of statements": { "content": "are provided to that effect. The 'set', 'unset', and 'map' statements\noperate on positional, request, and user-defined variables. The\n'setenv', 'unsetenv', 'clrenv', and 'keepenv' statements modify the\nenvironment. These will be discussed in a separate subsection (*note\nEnvironment::).\n\nModifications to positional and request variables deserve a special\nexplanation.\n\nThe only two request variables that can be modified (but not unset)\nare '$command' and '$program'.\n\nPositional variables and the '$command' request variable are mutually\ndependent. If the '$command' is modified, the word splitting is applied\nto it and resulting words are assigned to the positional variables.", "subsections": [] }, "Similarly, any modifications to positional variables trigger rebuilding": { "content": "of the '$command' variable from the modified arguments. *Note Modifying\nvariables::, for more detail on it.\n\nLet's consider several examples.\n\n1. Echo the command line\nrule\nset command = \"/bin/echo $command\"\n\n2. Remove all occurrences of '-r' option and its arguments from the\ncommand line, and then adds its own '-r' option and replaces\n'svnserve' with the full program file name.\n\nThere are at least three different ways to do so.\n\na. The recommended approach is to use the 'remopt' and 'insert'\nstatements, as shown below:\n\nrule svn\nmatch $command ~ \"^svnserve -t\"\nset program = \"/usr/bin/svnserve\"\nremopt r:\ninsert [1] = \"-r\"\ninsert [2] = \"/svnroot\"\n\nb. The same can be achieved using regular expressions. This was\nthe default in versions of 'rush' prior to 2.0:\n\nrule svn\nmatch $command ~ \"^svnserve -t\"\nset command =~ \"s/-r *[^ ]*//\"\nset command =~ \\\n\"s|^svnserve |/usr/bin/svnserve -r /svnroot |\"\n\nNotice the use of '|' as a delimiter in s-command, in order to\navoid escaping each '/' in the pathname. Without it, the\nexpression in the second 'set' command will be\n\n\"s/^svnserve /\\\\/usr\\\\/bin\\\\/svnserve -r \\\\/svnroot /\"\n\nc. The same rule, rewritten using the single 'set' statement:\n\nrule svn\nmatch $command ~ \"^svnserve -t\"\nset command =~ \"s|-r *[^ ]*||;\\\ns|^svnserve |/usr/bin/svnserve -r /svnroot |\"\n\n3. Override the executable program name.\n\nrule cvs\nmatch $command ~ \"^cvs server\"\nset [0] = /usr/bin/cvs\n", "subsections": [] }, "File: rush.info, Node: set, Next: insert, Up: Modifying variables": { "content": "4.4.3.1 The 'set' statement\n...........................\n", "subsections": [] }, "The 'set' statement modifies the value of a positional, request, or": { "content": "user-defined variable.\n\n-- rule: set NAME = VALUE\n-- rule: set [N] = VALUE\nSets the variable NAME to VALUE. Prior to use, VALUE undergoes\nbackreference interpretation (*note backreference::) and variable\nexpansion (*note Variable expansion::).\n\nThe second form assigns to the positional variable '$N'. It is\ndiscussed in more detail in *note Transformations::.\n\n-- rule: set NAME = VALUE ~ S-EXPR\n-- rule: set [N] = VALUE ~ S-EXPR\nApplies the 'sed' search-and-replace expression S-EXPR to VALUE and\nassigns the result to the variable NAME or argument N. Both VALUE\nand S-EXPR are subject to variable expansion and backreference\ninterpretation.\n\n-- rule: set NAME =~ S-EXPR\n-- rule: set [N] =~ S-EXPR\nApplies the 'sed'-like search-and-replace expression S-EXPR to the\ncurrent value of the variable NAME and stores the resulting string\nas its new value. Prior to use, S-EXPR undergoes backreference\ninterpretation (*note backreference::) and variable expansion\n(*note Variable expansion::). This is a shortcut for\n\nset NAME = ${NAME:-\"\"} ~ S-EXPR\n\nSecond form modifies the value of the positional variable '$N'.\nThis statement is a shortcut for\n\nset [N] = ${N:-\"\"} ~ S-EXPR\n\n*Note Transformations::, for a detailed discussion.\n\nThe transformation expression, S-EXPR, is 'sed'-like replace\nexpression of the form:\n\ns/REGEXP/REPLACE/[FLAGS]\n\nwhere REGEXP is a \"regular expression\", REPLACE is a replacement for\neach part of the input that matches REGEXP and FLAGS are optional flags\nthat control the substitution. Both REGEXP and REPLACE are described in\n*note The \"s\" Command: (sed)The \"s\" Command.\n\nAs in 'sed', you can give several replace expressions, separated by\nsemicolons.\n\nSupported FLAGS are:\n\n'g'\nApply the replacement to all matches to the REGEXP, not just the\nfirst.\n\n'i'\nUse case-insensitive matching\n\n'x'\nREGEXP is an \"extended regular expression\" (*note Extended regular\nexpressions: (sed)Extended regexps.).\n\n'NUMBER'\nOnly replace the NUMBERth match of the REGEXP.\n\nNote: the POSIX standard does not specify what should happen when\nyou mix the 'g' and NUMBER modifiers. 'Rush' follows the GNU 'sed'\nimplementation in this regard, so the interaction is defined to be:\nignore matches before the NUMBERth, and then match and replace all\nmatches from the NUMBERth on.\n\nNormally, the S-EXPR is a quoted string, and as such it is subject to\nbackslash interpretation. It is therefore important to properly escape\nbackslashes, especially in REPLACE part. Consider this example:\n\nset bindir = $program ~ \"s/(.*)\\\\//\\\\1/\"\n\nThe intention is to extract the directory part of the executable\nprogram name and store it in the variable 'bindir'. Notice, that each\nbackslash is escaped, so that the actual string that is compiled into a\nregular expression is\n\ns/(.*)\\//\\1/\n", "subsections": [] }, "File: rush.info, Node: insert, Next: unset, Prev: set, Up: Modifying variables": { "content": "4.4.3.2 The 'insert' statement\n..............................\n", "subsections": [] }, "The 'insert' statement inserts new positional argument at a given": { "content": "position. Its syntax is similar to 'set':\n\n-- rule: insert [N] = VALUE\n-- rule: insert [N] = VALUE ~ S-EXPR\nShift arguments starting from N one position to the right (so that\nN becomes N+1 etc.) and insert VALUE at 'argv[N]'.\n\nIn the second form, the value to be inserted is computed by\napplying sed-expression S-EXPR to VALUE.\n\nBoth VALUE and S-EXPR are subject to variable expansion and\nbackreference interpretation.\n\nExample using this statement to insert the '--root=/tmp' argument at\nposition 1:\n\ninsert [1] = \"--root=/tmp\"\n", "subsections": [] }, "Note that when inserting multiple arguments (e.g. an option with a": { "content": "value), you have two possibilities. First, you can insert each argument\nat its corresponding position. For example, to insert two arguments\n'--root' and '/tmp' starting at position 1, one can use:\n\ninsert [1] = \"--root\"\ninsert [2] = \"/tmp\"\n", "subsections": [] }, "Otherwise, you can revert the arguments and insert them at the same": { "content": "position, as shown in the example below:\n\ninsert [1] = \"/tmp\"\ninsert [1] = \"--root\"\n", "subsections": [] }, "File: rush.info, Node: unset, Next: remopt, Prev: insert, Up: Modifying variables": { "content": "4.4.3.3 The 'unset' statement\n.............................\n\n-- rule: unset NAME\nUnset the variable NAME.\n\n-- rule: unset N\nUnset the positional argument N (an integer number greater than 0),\nshifting the remaining arguments one position left. The effect is\nthe same as from 'delete' (*note delete::).\n", "subsections": [] }, "File: rush.info, Node: remopt, Next: delete, Prev: unset, Up: Modifying variables": { "content": "4.4.3.4 The 'remopt' statement\n..............................\n", "subsections": [] }, "The 'remopt' statement removes from the command line all occurrences of": { "content": "the supplied option.\n\n-- rule: remopt SOPT\n-- rule: remopt SOPT LOPT\nRemove from the command line all occurrences of the short option\ndescribed by SOPT. The SOPT argument is the short option letter,\noptionally followed by a colon if that option takes a mandatory\nargument, or by two colons if it takes an optional argument.\n\nOptional LOPT supplies a long option equivalent to SOPT. If no\nshort option equivalent exists, use '' as SOPT, eventually\nfollowed by ':' or '::'.\n\nFor example, to remove all occurrences of the '-r' ('--root') option\nthat takes a mandatory argument, use:\n\nremopt r: root\n", "subsections": [] }, "File: rush.info, Node: delete, Next: map, Prev: remopt, Up: Modifying variables": { "content": "4.4.3.5 The 'delete' statement\n..............................\n\nAnother statement modifying the command line is 'delete':\n\n-- rule: delete N\nDelete Nth argument.\n\n-- rule: delete I J\nDelete positional parameters between '$I' and '$J', inclusive.\n\nNeither form can be used to delete the program name ('$0').\n\nFor example, the following statement deletes all arguments from the\ncommand line, except for the program name:\n\ndelete 1 -1\n\nTo delete a single argument, 'unset' can also be used. The following\nstatements have the same effect:\n\ndelete 2\nunset 2\n", "subsections": [] }, "File: rush.info, Node: map, Prev: delete, Up: Modifying variables": { "content": "4.4.3.6 The 'map' statement\n...........................\n\n-- rule: map NAME FILE DELIM KEY KN VN\n-- rule: map [N] FILE DELIM KEY KN VN DEFAULT\nThe 'map' statement uses file lookup to find a new value for the\nvariable NAME (or, in its second form, for the positional variable\n'$N').\n\nArguments are:\n\nFILE\nName of the \"map file\". It must begin with '/' or '~/'.\nBefore using, the file permissions and ownership are checked\nusing the procedure described in *note security checks::.\n\nDELIM\nA string containing allowed field delimiters.\n\nKEY\nThe value of the lookup key. Before using, it undergoes\nbackslash interpretation and variable expansion.\n\nKN\nNumber of the key field in FILE. Fields are numbered starting\nfrom 1.\n\nVN\nNumber of the value field.\n\nDEFAULT\nIf supplied, this value is used as a replacement value, when\nthe key was not found in FILE.\n\nThe map file consists of \"records\", separated by newline characters\n(in other words, a record occupies one line). Each record consists of\nfields, separated by delimiters listed in DELIM argument. If DELIM\ncontains a space character, then fields may be delimited by any amount\nof whitespace characters (spaces and/or tabulations). Otherwise,\nexactly one delimiter delimits fields.\n\nFields are numbered starting from 1.\n\nThe 'map' action works as follows:\n\n1. Variable expansion is performed on the KEY argument (*note Variable\nexpansion::) and the resulting value is used as lookup key.\n\n2. The FILE is scanned for a record whose KNth field matches the\nlookup key.\n\n3. If such a record is found, the value of its VNth field is assigned\nto the variable.\n\n4. Otherwise, if DEFAULT is supplied, it becomes the new value of the\nvariable.\n\n5. Otherwise, the variable remains unchanged.\n\nFor example, suppose that the file '/etc/passwd.rush' has the same\nsyntax as the system 'passwd' file (*note Password File:\n(passwd(5))passwd.). Then, the following statement will replace '$0'\nwith the value of 'shell' field, using the current user name as a key:\n\nmap [0] /etc/passwd.rush : ${user} 1 7\n\nSee also *note Interactive::, for another example of using this\nstatement.\n", "subsections": [] }, "File: rush.info, Node: Environment, Next: Transformations, Prev: Modifying variables, Up: Rule": { "content": "", "subsections": [] }, "The following actions modify the environment in which the program will": { "content": "be executed.\n\n-- rule: clrenv\nClear the environment.\n\n-- rule: keepenv LIST\nRetain the names in LIST in the environment. This statement should\nbe used in conjunction with 'clrenv'.\n\nArgument is a whitespace delimited list of variables to retain.\nEach element in the list can be either a variable name, or a\nshell-style globbing pattern, in which case all variables matching\nthat pattern will be retained, or a variable name followed by an\nequals sign and a value, in which case it will be retained only if\nits actual value equals the supplied one. For example, to retain\nonly variables with names beginning with 'LC':\n\nkeepenv \"LC*\"\n\n-- rule: setenv NAME = VALUE\nSet the environment variable NAME. The VALUE argument is subject\nto variable expansion (*note Variable expansion::) and\nbackreference interpretation (*note backreference::).\n\nFor example, to modify the 'PATH' value:\n\nsetenv PATH = \"$PATH:/opt/bin\"\n\n-- rule: unsetenv LIST\nUnset environment variables listed as arguments.\n\nArgument is a whitespace delimited list of variables to retain.\nEach element in the list can be either a variable name, or a\nshell-style globbing pattern, in which case all variables matching\nthat pattern will be unset, or a variable name followed by an\nequals sign and a value, in which case it will be unset only if its\nactual value equals the supplied one.\n\n-- rule: evalenv STRING\nPerforms backslash interpretation, backreference interpretation and\nvariable expansion on STRING and discards the result. This\nstatement is similar to the shell's \"colon\" statement. For\nexample, the following statement will define the 'DEPTH' variable\nand initialize it to 10, unless it is already defined:\n\nevalenv ${DEPTH:=10}\n", "subsections": [] }, "File: rush.info, Node: Transformations, Next: System Actions, Prev: Environment, Up: Rule": { "content": "", "subsections": [] }, "Transformations are special actions that modify entire command line or": { "content": "particular arguments from it (positional variables).\n\nStatements that modify variable have been described in the previous\nsection: these are 'set', 'insert', 'unset', 'remopt', 'delete' and\n'map' statements. When 'set' or 'map' is applied to the 'command'\nvariable, it modifies entire command line. When these statements are\napplied to an index ('[N]'), they modify the corresponding positional\nvariable (argument). This subsection discusses the implications of\nmodifying these variable and illustrates them with some examples.\n\nPositional variables and the '$command' request variable are mutually\ndependent. If the '$command' is modified, the word splitting is applied\nto it and resulting words are assigned to the positional variables.", "subsections": [] }, "File: rush.info, Node: System Actions, Next: Fall-through, Prev: Transformations, Up: Rule": { "content": "System actions provide an interface to the operating system.\n\n-- rule: umask MASK\nSet the umask. The MASK must be an octal value not greater than\n'0777'. The default umask is '022'.\n\n-- rule: newgrp GROUP-ID\n-- rule: newgroup GROUP-ID\nChange the current group ID to GROUP-ID, which is either a numeric\nvalue or a name of an existing group.\n\n-- rule: chroot DIR\nChange the root directory to that specified in DIR. This directory\nwill be used for file names beginning with '/'. The argument is\nsubject to tilde, variable, and backreference expansions. During\ntilde expansion, a tilde ('~') at the start of string is replaced\nwith the absolute pathname of the user's home directory. The two\nother expansions are described in *note Variable expansion::, and\n*note backreference::.\n\nThe directory DIR must be properly set up to execute the commands.", "subsections": [] }, "For example, the following rule defines execution of 'sftp-server' in an": { "content": "environment chrooted to the user's home directory:\n\nrule sftp\nmatch $program ~ \"^.*/sftp-server\"\nset [0] = \"bin/sftp-server\"\nchroot \"~\"\n\nFor this to work, each user's home must contain the directory 'bin'\nwith a copy of 'sftp-server' in it, as well as all directories and files\nthat are needed for executing it, in particular 'lib'.\n\n-- rule: chdir DIR\nChange to the directory DIR. The argument is subject to tilde,\nvariable (*note Variable expansion::), and backreference expansions\n(*note backreference::). If both 'chdir' and 'chroot' are\nspecified, then 'chroot' is applied first.\n\n-- rule: limits RES\nImpose limits on system resources, as defined by RES. The argument\nconsists of \"commands\", optionally separated by any amount of\nwhitespace. A command is a single command letter followed by a\nnumber, that specifies the limit. The command letters are\ncase-insensitive and coincide with those used by the shell 'ulimit'\nutility:\n\nA max address space (KB)\nC max core file size (KB)\nD max data size (KB)\nF maximum file size (KB)\nM max locked-in-memory address space (KB)\nN max number of open files\nR max resident set size (KB)\nS max stack size (KB)\nT max CPU time (MIN)\nU max number of processes\nL max number of logins for this user (see\nbelow)\nP process priority -20..20 (negative = high\npriority)\n\nFor example:\n\nlimits T10 R20 U16 P20\n\nIf some limit cannot be set, execution of the rule aborts. In\nparticular, the 'L' limit can be regarded as a condition, rather\nthan an action. Setting 'limit LN' succeeds only if no more than N\n'rush' instances are simultaneously running for the same user.\nThis can be used to limit the number of simultaneously open\nsessions.\n\nThe use of 'L' resource automatically enables \"forked mode\". *Note\nAccounting and Forked Mode::, for more information about it.\n", "subsections": [] }, "File: rush.info, Node: Fall-through, Next: Accounting and Forked Mode, Prev: System Actions, Up: Rule": { "content": "The \"fall-through\" statement is a special action that does not execute\nthe requested command. When a matching fall-through rule is\nencountered, 'rush' evaluates it and continues scanning its\nconfiguration for the next matching rule. Any modifications to the\nrequest found in the fall-through rule take effect immediately, which\nmeans that subsequent rules will see modified command line and\nenvironment. Execution of any other actions found in the fall-through\nrule is delayed until a usual rule is found.\n\nA fall-through rule is declared using the following statement:\n\n-- rule: fall-through\n-- rule: fallthrough\nDeclare a fall-through rule.\n\nUsually this statement is placed as the last statement in a rule,\ne.g.:\n\nrule default\numask 002\nclrenv\nkeepenv HOME USERNAME PATH\nfall-through\n\nFall-through rules provide a way to set default values for subsequent\nrules. For example, any rules that follow the 'default' rule shown\nabove, will inherit the umask and environment set there.\n\nOne can also use fall-through rules to \"normalize\" command lines.\nFor example, consider this rule:\n\nrule default\nset [0] =~ \"s|.*/||\"\nfall-through\n\nIt will remove all path components from the first command line\nargument. As a result, all subsequent rules may expect a bare binary\nname as the first argument.\n\nYet another common use for such rules is to enable accounting (see\nthe next subsection), or set resource limits for the rest of rules:\n\nrule default\nlimit l1\nfall-through\n", "subsections": [] }, "File: rush.info, Node: Accounting and Forked Mode, Next: Notification, Prev: Fall-through, Up: Rule": { "content": "GNU Rush is able to operate in two modes, which we call default and\nforked. When operating in the default mode, the process image of 'rush'\nitself is overwritten by the command being executed. Thus, when it\ncomes to launching the requested command, the running instance of 'rush'\nceases to exist.\n\nThere is also another operation mode, which we call \"forked mode\".", "subsections": [] }, "When running in this mode, 'rush' executes the requested command in a": { "content": "subprocess, and remains in memory supervising its execution. Once the\ncommand terminates, 'rush' exits.\n\nOne advantage of the forked mode is that it allows you to keep\n\"accounting\", i.e. to note who is doing what and to keep a history of\ninvocations. The accounting, in turn, can be used to limit simultaneous\nexecutions of commands (\"logins\", in GNU Rush terminology), as requested\nby 'L' command to 'limit' statement (*note L limit::).\n\nThe forked mode is enabled on a per-rule basis, for rules that\ncontain either 'L' command in the 'limit' statement, or 'acct on'\ncommand:\n\n-- rule: acct BOOL\nTurn accounting mode on or off, depending on BOOL. The argument\ncan be one of the following: 'yes', 'on', 't', 'true', or '1', to\nenable accounting, and 'no', 'off', 'nil', 'false', '0', to disable\nit.\n\nNotice, that there is no need in explicit 'acct on' command, if you\nuse 'limit L'.\n\nThe notion 'rule contains', used above, means that either the rule in\nquestion contains that statement, or inherits it from one of the\nfall-through rules (*note Fall-through::) that were matched before it.", "subsections": [] }, "In fact, in most cases the accounting should affect all rules, therefore": { "content": "we suggest to enable it in a fall-through rule at the beginning of the\nconfiguration file, e.g.:\n\nrule default\nacct on\nfall-through\n\nIf the need be, you can disable it for some of the subsequent rules\nby placing 'acct off' in it. Notice, that this will disable accounting\nonly, the forked mode will remain in action. To disable it as well and\nenforce default mode for a given rule, use the following statement:\n\n-- rule: fork BOOL\nEnable or disable forked mode. This statement is mainly designed\nas a way of disabling the forked mode for a given rule.\n\nOnce accounting is enabled, you can use the 'rushwho' command to see\nthe list of users presently running some commands (*note Rushwho::) and\nview the history of last accesses using 'rushlast' command (*note\nRushlast::).\n", "subsections": [] }, "File: rush.info, Node: Notification, Next: Exit, Prev: Accounting and Forked Mode, Up: Rule": { "content": "'Rush' can be configured to send a \"notification\" over INET or UNIX\nsockets, after completing user request. It is done using the\n'post-socket' statement:\n\n-- rule: post-socket URL\nNotify URL about completing the user request. This statement\nimplies forked mode (*note Accounting and Forked Mode::).\n\nAllowed formats for URL are:\n\ninet://HOSTNAME[:PORT]\n\nConnect to remote host HOSTNAME using TCP/IP. HOSTNAME is the\nhost name or IP address of the remote machine. Optional PORT\nspecifies the port number to connect to. It can be either a\ndecimal port number or a service name from '/etc/services'.\nIf PORT is absent, 'tcpmux' (port 1) is assumed.\n\nunix://FILENAME\nlocal://FILENAME\n\nConnect to a UNIX socket FILENAME.\n\nFor example:\n\nrule default\npost-socket \"inet://localhost\"\n\nThe GNU Rush notification protocol is based on TCPMUX (RFC 1078\n(http://www.rfc-editor.org/rfc/rfc1078.txt)).\n\nAfter establishing connection, 'rush' sends the rule tag followed by\na CRLF pair. The rule tag acts as a service name. The remote party\nreplies with a single character indicating positive ('+') or negative\n('-') acknowledgment, optionally followed by a message of explanation,\nand terminated with a CRLF.\n\nIf positive acknowledgment is received, 'rush' sends a single line,\nconsisting of the user name and the executed command line, separated by\na single space character. The line is terminated with a CRLF.\n\nAfter sending this line, 'rush' closes the connection.\n\nThe post-process notification feature can be used to schedule\nexecution of some actions after certain rules.\n\n*Note notification example::, for an example of how to use this\nfeature.\n", "subsections": [] }, "File: rush.info, Node: Exit, Next: Interactive, Prev: Notification, Up: Rule": { "content": "The \"exit\" rule does not execute any commands. Instead, it writes the\nsupplied error message to the specified file descriptor and exits\nimmediately. The exit rule is defined using the following statement:\n\n-- rule: exit FD MESSAGE\n-- rule: exit MESSAGE\nWrite textual message MESSAGE to a file descriptor, given by the\noptional argument FD. If FD is absent, '2' (standard error) is\nused.\n\nThe MESSAGE argument can be either a quoted string, or an identifier.\n\nIf it is a quoted string, it is subject to backreference\ninterpretation and variable expansion prior to being used.\n\nFor example (note the use of line continuation character):\n\nexit \"\\\n\\r\\nYou are not allowed to execute that command.\\r\\n\\\n\\r\\nIf you think this is wrong, ask for assistance.\\r\\n\"\n\nIf MESSAGE is an identifier, it must be the name of a predefined\nerror message (*note Error Messages::). The corresponding message text\nwill be printed. For example:\n\nexit nologin-message\n\nIf the identifier does not match any predefined error message name,\nan error of type 'config-error' is signaled and 'rush' exits.\n\nExit actions are useful for writing \"trap rules\", i.e. the rules\nthat are intended to trap incorrect or prohibited command lines and to\nreturn customized reply messages in such cases. Consider the following\nrule:\n\nrule git\nmatch $program ~ \"^git-.+\" && $1 ~ \"^/sources/[^ ]+\\.git$\"\nset command =~ \"s|.*|/usr/bin/git-shell -c \\\"&\\\"|\"\n\nIt allows the client to use only those Git repositories that are\nlocated under '/sources' directory(1). If a user tries to access a\nrepository outside this root, he will be returned a default error\nmessage, saying 'You are not permitted to execute this command' (*note\nusage-error: Error Messages.). You can, however, provide a more\nconvenient message in this case. To do so, place the following after\nthe 'git' rule:\n\nrule git-trap\nmatch $command ~ \"^git-.+\"\nexit \"fatal: Use of this repository is prohibited.\"\n", "subsections": [] }, "This rule will trap all git invocations that do not match the 'git'": { "content": "rule.\n\n---------- Footnotes ----------\n\n(1) *Note git::, for a better way to handle Git accesses.\n", "subsections": [] }, "File: rush.info, Node: Interactive, Next: Localization, Prev: Exit, Up: Rule": { "content": "", "subsections": [] }, "Sometimes it may be necessary to allow some group of users limited": { "content": "access to interactive shells. GNU Rush contains provisions for such\nusage. When 'rush' is invoked without '-c' it assumes interactive\nusage. In this case only rules explicitly marked as interactive are\nconsidered, the rest of rules is ignored.\n\n-- rule: interactive BOOL\nIf BOOL is 'true', this statement marks the rule it appears in as\ninteractive. This rule will match only if 'rush' is invoked\nwithout command line arguments.\n\nUnless command line transformations are applied, interactive rule\nfinishes by executing '/bin/sh'. The first word in the command line\n('argv[0]') is normally set to the base name of the command being\nexecuted prefixed by a dash sign.\n\nConsider the following example:\n\nrule login\ninteractive true\ngroup rshell\nmap program /etc/rush.shell : ${user} 1 2\nset [0] = ${program} ~ \"s|^.*/||;s,^,-r,\"\n\nrule nologin\ninteractive true\nexit You don't have interactive access to this machine.\n\nThe 'login' rule will match interactive user requests if the user is\na member of the group 'rshell'. It uses '/etc/rush.shell' to select a\nshell to use for that user (*note map::). This map file consists of two\nfields, separated by a colon. If the shell is found, its base name,\nprefixed with '-r', will be used as 'argv[0]' (this indicates a\nrestricted login shell). Otherwise, the trap rule 'nologin' will be\nmatched, which will output the given diagnostics message and terminate\n'rush'.\n\nTo test interactive access, use the '-i' option:\n\nrush --test -i\n", "subsections": [] }, "File: rush.info, Node: Localization, Prev: Interactive, Up: Rule": { "content": "GNU Rush is internationalized, which means that it is able to produce\nlog and diagnostic messages in any language, if a corresponding\ntranslation file is provided. This file is called a \"localization\" or\n\"domain\" file. To find an appropriate localization file, 'rush' uses\nthe following parameters:\n", "subsections": [] }, "LOCALE": { "content": "\"Locale name\" is a string that describes the language, territory\nand optionally, the character set to use. It consists of the\nlanguage (ISO 639) and country (ISO 3166) codes, separated by an\nunderscore character, e.g. 'enUS' or 'plPL'. If a character set\nis specified, its name follows the country code and is separated\nfrom it by a '@' character.\n\nThere are two special locale names: 'C' or 'POSIX' mean to use the\ndefault POSIX locale, and '\"\"' (an empty string), means to use the\nvalue of the environment variable 'LCALL' as the locale name.\n", "subsections": [] }, "LOCALEDIR": { "content": "Directory where localization files are located. If not specified,\na predefined set of directories is searched for the matching file.\n", "subsections": [] }, "DOMAIN": { "content": "\"Text domain\" defines the base name of the localization file.\n\nGiven these parameters, the name of the full pathname of the\nlocalization file is defined as:\n\nLOCALEDIR/LOCALE/LCMESSAGES/DOMAIN.mo\n\nGNU Rush produces three kinds of messages:\n\ndiagnostics\nThese are diagnostics messages that GNU Rush produces to its log\noutput (syslog, unless in test mode).\n\nerror messages\nMessages sent to the remote party when 'rush' is not able to\nexecute the request (*note Error Messages::).\n\nexit messages\nThese are messages sent to the remote party by 'exit' rules (*note\nExit::).\n\nThese messages use different domain names (and may use different\nlocale directories). The diagnostics and error messages use textual\ndomain 'rush'. The corresponding locale directory is defined at compile\ntime and defaults to 'PREFIX/share/locale', where PREFIX stands for the\ninstallation prefix, which is '/usr/local', by default.\n\nGNU Rush is shipped with several localization files, which are\ninstalled by default. As of version 2.3, these files cover the\nfollowing languages: Chinese, Danish, Dutch, Finnish, French, Galician,", "subsections": [] }, "German, Polish, Portuguese, Serbian, Spanish, Swedish, Ukrainian, and": { "content": "", "subsections": [] }, "Vietnamese. If the localization you need is not in this list, visit": { "content": ". If it is not there\neither, consider writing it (see *note (gettext)Translators::, for a\ndetailed instructions on how to do that).\n\nExit messages use custom domain files. It is the responsibility of\nthe system administrator to provide and install such files.\n\n* Menu:\n\n* Localization Directives::\n* Writing Your Localization::\n", "subsections": [] }, "File: rush.info, Node: Localization Directives, Next: Writing Your Localization, Up: Localization": { "content": "4.4.12.1 Localization Directives\n................................\n", "subsections": [] }, "The following configuration directives control localization. They are": { "content": "available for use in 'rule' statements:\n\n-- rule: locale NAME\nSets the locale name. To specify empty locale, use '\"\"' as NAME\n(recall that empty locale name means to use the value of the\nenvironment variable 'LCALL' as locale name).\n\n-- rule: locale-dir NAME\nSets the name of the locale directory.\n\n-- rule: text-domain NAME\nSets the textual domain name.\n\nThe following configuration fragment illustrates their use:\n\nrule l10n\nlocale \"plPL\"\ntext-domain \"rush-config\"\nfall-through\n\nDifferent users may have different localization preferences. *Note\nper-user l10n::, for a description of how to implement this.\n", "subsections": [] }, "File: rush.info, Node: Writing Your Localization, Prev: Localization Directives, Up: Localization": { "content": "4.4.12.2 Writing Your Localization\n..................................\n", "subsections": [] }, "You need to write a localization file for your configuration script if": { "content": "it implements exit rules (*note Exit::) and changes user locale (*note\nlocale: Localization Directives.).\n\nPreparing a localization consists of three stages: extracting exit\nmessages and forming a PO file, editing this file, compiling and\ninstalling it. The discussion below describes these stages in detail.\n\n1. Creating a 'po' file.\n\nA PO (\"Portable Object\") file is a plain text file, containing\noriginal messages and their translations for a particular language.\n*Note The Format of PO Files: (gettext)PO Files, for a description\nof its format.\n\nThe script 'rush-po' extracts translatable messages from the\nconfiguration file and produces a valid PO file. It takes the name\nof the rush configuration file as its argument and produces the PO\nfile on the standard output, or in the file given with the '-o'\n('--output') option. E.g., to create a PO file from your\nconfiguration file, run:\n\nrush-po -o myconf.po /usr/local/etc/rush.rc\n\n2. Editing the PO file\n\nOpen the created PO file with your favorite editor and supply\nmessage translations after 'msgstr' keywords. Although you can use\nany editor capable of handling plain text files, we recommend to\nuse GNU Emacs, which provides a special \"po-mode\". *Note PO Files\nand PO Mode Basics: (gettext)Basics, for guidelines on editing PO\nfiles and using the po-mode.\n\n3. Compiling the PO file\n\nWhen ready, the PO file needs be compiled into a MO (\"Message\nObject\") file, which is directly readable by 'rush'. This is done\nusing 'msgfmt' utility from GNU gettext:\n\nmsgfmt -o myconf.mo myconf.po\n\n*Note (gettext)msgfmt Invocation::, for a detailed description of\nthe 'msgfmt' utility.\n\nAfter creating the MO file, copy it into appropriate directory. It\nis important that the installed MO file uses the naming scheme\ndescribed in *note localization file naming: mo-name.\n", "subsections": [] }, "File: rush.info, Node: Include, Prev: Rule, Up: Configuration File": { "content": "", "subsections": [ { "name": "4.5 Include", "content": "" } ] }, "The 'include' statement forces inclusion of the named file in that file": { "content": "location:\n\n-- rule: include FILE\nInclude file FILE.\n\nThe statement is evaluated when parsing the configuration file, which\nmeans that FILE undergoes only \"tilde expansion\": the two characters\n'~/' appearing at the beginning of FILE are replaced with the full path\nname of the current user's home directory.\n\nIf FILE is a directory, that directory is searched for a file whose\nname coincides with the current user name. If such a file is found, it\nis included.\n\nIn any case, if the file named by FILE (after tilde expansion) does\nnot exist, no error is reported, and parsing of the configuration file\ncontinues.\n\nBefore including the file 'rush' checks if it is secure, using the\nsame rules as for the main configuration file (*note security checks::).", "subsections": [] }, "The exact list of checks can be tuned using the 'include-security'": { "content": "statement (*note include-security::).\n\nThe 'include' statement can be used only within a rule. The included\nfile may not contain 'rule' and 'global' statements.\n\nThis statement provides a convenient way for user-dependent 'rush'\nconfiguration. For example, the following fall-through rule (*note", "subsections": [] }, "Fall-through::) allows the administrator to keep each user personal": { "content": "configuration in a file named '.rush', located in the user's home\ndirectory:\n\nrule user\ninclude \"~/.rush\"\nfall-through\n\nOf course, it is supposed that such a per-user file, if it exists, is\nwritable only for super-user.\n\nThe use of include files may be especially useful for per-user\nlocalization (*note Localization::). It suffices to provide a\nfall-through rule, similar to the one above, and to place a 'locale'\ndirective in '~/.rush' files, according to the user preferences.\n", "subsections": [] }, "File: rush.info, Node: Default Configuration, Next: Usage Tips, Prev: Configuration File, Up: Top": { "content": "", "subsections": [] }, "5 Default Configuration": { "content": "", "subsections": [] }, "You can compile 'rush' with the default configuration built in the": { "content": "binary. Such a binary can then be run without configuration file.", "subsections": [] }, "However, if a configuration file is present, it will be used instead of": { "content": "the built-in configuration.\n\nTo compile 'rush' with the built-in configuration, first compile the\npackage as usual. Then, prepare a configuration file, and test it using\n'rush --lint'. If the test shows no errors, reconfigure the package,\nusing the '--with-default-config' option:\n\n./configure --with-default-config=FILE\n\nwhere FILE is the name of your configuration file. Then, recompile and\ninstall the package.\n\nYou can inspect the built-in configuration using the '--show-default'\noption:\n\nrush --show-default\n", "subsections": [] }, "File: rush.info, Node: Usage Tips, Next: Test Mode, Prev: Default Configuration, Up: Top": { "content": "", "subsections": [] }, "6 Usage Tips": { "content": "", "subsections": [] }, "In this chapter we will explain how to write GNU Rush configuration": { "content": "rules for several popular remote copy and version control system\nutilities. For this purpose, we assume the following setup:\n\n* Users are allowed to use 'scp' and 'rsync' to upload files to the\n'/incoming' directory and to copy files to and from their\n'~/publichtml' directory. The actual location of the '/incoming'\ndirectory is '/home/ftp', but that must be transparent to users,\ni.e. they use 'scp FILE HOST:/incoming' (not\n'HOST:/home/ftp/incoming') to upload files.\n\n* Additionally, users may use 'sftp' to manage their '~/publichtml'\ndirectory. In this case, to prevent users from accessing other\ndirectories, 'sftp-server' is executed in a chrooted environment.\n\n* The server runs three version control system repositories, whose\ncorresponding root directories are:\n\ncvs /cvsroot\nsvn /svnroot\ngit /gitroot\n\n* Menu:\n\n* scp::\n* rsync::\n* sftp::\n* cvs::\n* svn::\n* git::\n* notification example::\n", "subsections": [] }, "File: rush.info, Node: scp, Next: rsync, Up: Usage Tips": { "content": "", "subsections": [ { "name": "6.1 scp", "content": "" } ] }, "The 'scp' utility is executed on the server side with option '-t', when": { "content": "copying files to server, and with '-f' when copying from it. Thus, the\nbasic templates for 'scp' rules are:\n\n# Copying to server:\nrule scp-to\nmatch $command ~ \"^scp -t\"\n...\n\n# Copying from server:\nrule scp-from\nmatch $command ~ \"^scp -f\"\n...\n\nYou may also wish to allow for '-v' ('verbose') command line option.\nIn this case, the 'scp-to' rule will become:\n\nrule scp-to\nmatch $command ~ \"^scp (-v )?-t\"\n...\n\nNow, we want users to be able to upload files to '/home/ftp/incoming'\ndirectory. Moreover, the '/home/ftp' directory prefix must be invisible\nto them. We should also make sure that the user cannot get outside the\n'incoming' directory by using '../' components in his upload path. So,\nour first rule for 'scp' uploads will be:\n\nrule scp-to-incoming\nmatch $command ~ \"^scp (-v )?-t /incoming/\" && \\\n${-1} !~ \"\\\\.\\\\./\"\nset command \"/bin/scp\"\nset [-1] =~ \"s|^|/home/ftp/|\"\n\nThe 'match' statement ensures that no relative components are used.", "subsections": [] }, "The two 'set' statements ensure that the right 'scp' binary is used and": { "content": "that '/home/ftp' prefix is prepended to the upload path.\n\nOther than uploading to '/incoming', users must be able to use 'scp'\nto manage 'publichtml' directories located in their homes. They should\nuse relative paths for that, i.e., the command:\n\n$ scp file.html server:\n\nwill copy file 'file.html' to '~/publichtml/file.html' on the server.\nThe corresponding rule is:\n\nrule scp-home\nmatch $command ~ \"^scp (-v )?-[tf] [^/].*\" && \\\n${-1} !~ \"\\\\.\\\\./\"\nset [0] = \"/bin/scp\"\nset [-1] =~ \"s|^|publichtml/|\"\nchdir \"~\"\n\nFinally, we provide two trap rules for diagnostic purposes:\n\nrule scp-to-trap\nmatch $command ~ \"^scp (-v )?-t\"\nexit \"Error: Uploads to this directory prohibited\"\n\nrule scp-from\nmatch $command ~ \"^scp (-v )?-f\"\nexit Error: Downloads from this directory prohibited\n", "subsections": [] }, "File: rush.info, Node: rsync, Next: sftp, Prev: scp, Up: Usage Tips": { "content": "", "subsections": [ { "name": "6.2 rsync", "content": "" } ] }, "On the server side, 'rsync' is executed with the '--server' command line": { "content": "option. In addition, when copying files from the server, the '--sender'\noption is used. This makes it possible to discern between incoming and\noutgoing requests.\n\nIn our setup, 'rsync' is used the same way as 'scp', so the two rules\nwill be:\n\nrule rsync-incoming\nmatch $command ~ \"^rsync --server\" && \\\n$command !~ --sender && \\\n${-1} ~ \"/incoming/\" && ${-1} !~ \"\\\\.\\\\./\"\nset [0] =~ \"s|^|/usr/bin/|\"\nset [-1] =~ \"s|^|/home/ftp/|\"\n\nrule rsync-home\nmatch $command ~ \"^rsync\" && \\\n${-1} !~ \"^[^/]\" && \\\n${-1} !~ \"\\\\.\\\\./\"\nset [0] = \"s|^|/usr/bin/|\"\nset [-1] =~ \"s|^|publichtml/|\"\nchdir \"~\"\n\nThe trap rules for 'rsync' are trivial:\n\nrule rsync-to-trap\nmatch $command ~ \"^rsync.*--sender\"\nexit \"Error: Downloads from this directory prohibited\"\n\nrule rsync-from-trap\nmatch $command ~ \"^rsync\"\nexit \"Error: Uploads to this directory prohibited\"\n", "subsections": [] }, "File: rush.info, Node: sftp, Next: cvs, Prev: rsync, Up: Usage Tips": { "content": "", "subsections": [ { "name": "6.3 sftp", "content": "" } ] }, "Executing 'sftp' on the client machine invokes 'sftp-server', without": { "content": "arguments, on the server.\n\nWe want to allow our users to use 'sftp' to manage their\n'publichtml' directories. The 'sftp-server' will be executed with the\nuser's home directory as root, in a chrooted environment. For this to\nwork, each user's home must contain a copy of 'sftp-server' (which we'll\nplace in '~/bin' subdirectory) and all files it needs for normal\nexecution: '/etc/group' and '/etc/passwd' with one entry (for the user\nand his group), and, unless the binary is linked statically, all the\nshared libraries it is linked with, in the subdirectory '~/lib'.\n\nGiven these prerequisites, the following rule will ensure proper\n'sftp' interaction:\n\nrule sftp-incoming\nmatch $command ~ \"^.*/sftp-server\"\nset [0] = \"/bin/sftp-server\"\nchroot \"~\"\nchdir \"publichtml\"\n", "subsections": [] }, "Notice the last action. Due to it, users don't have to type 'cd": { "content": "publichtml' at the beginning of their sftp sessions.\n", "subsections": [] }, "File: rush.info, Node: cvs, Next: svn, Prev: sftp, Up: Usage Tips": { "content": "", "subsections": [ { "name": "6.4 cvs", "content": "" } ] }, "Using 'cvs' over 'ssh' invokes 'cvs server' on the server machine. In": { "content": "the simplest case, the following rule will do to give users access to\nCVS repositories:\n\nrule cvs\nmatch $command ~ \"^cvs server\"\nset command ~ \"s|^cvs|/usr/bin/cvs -f\"\n\nHowever, 'cvs' as of version 1.12.13 does not allow to limit root\ndirectories that users are allowed to access. It does have\n'--allow-root' option, but unfortunately this option is ignored when\ninvoked as 'cvs server'. To restrict possible roots, we have to run\n'cvs' in a chrooted environment. Let's suppose we created an\nenvironment for 'cvs' in directory '/var/cvs', with the 'cvs' binary\nlocated in '/var/cvs/bin' and repository root directory being\n'/var/cvs/cvsroot'. Then, we can use the following rule:\n\nrule cvs\nmatch $command ~ \"^cvs server\"\nset [0] = \"/bin/cvs\"\nchroot \"/var/cvs\"\n", "subsections": [] }, "File: rush.info, Node: svn, Next: git, Prev: cvs, Up: Usage Tips": { "content": "", "subsections": [ { "name": "6.5 svn", "content": "" } ] }, "Remote access to SVN repositories is done via 'svnserve' binary. It is": { "content": "executed on server with '-t' option. The '-r' option can be used to\nrestrict access to a subset of root directories. So, we can use the\nfollowing rule:\n\nrule svn\nmatch $command ~ \"^svnserve -t\"\nset command =~ \"s|-r *[^ ]*||\"\nset command =~ \\\n\"s|^svnserve |/usr/bin/svnserve -r /svnroot|\"\n\nThe first 'set command' action removes any '-r' options the user\nmight have specified and enforces a single root directory. A more\nrestrictive action can be used to improve security:\n\nset command =~ \"s|.*|/usr/bin/svnserve -r /svnroot|\"\n", "subsections": [] }, "File: rush.info, Node: git, Next: notification example, Prev: svn, Up: Usage Tips": { "content": "", "subsections": [ { "name": "6.6 git", "content": "" } ] }, "Remote access to Git repositories over ssh causes execution of": { "content": "'git-receive-pack' and 'git-upload-pack' on the server. The simplest\nrule for Git is:\n\nrule git\nset $command ~ \"^git-(receive|upload)-pack\"\nset [0] =~ \"s|^|/usr/bin/|\"\n", "subsections": [] }, "The 'set' action is necessary to ensure the proper location of Git": { "content": "binaries to use. This example supposes they are placed in '/usr/bin',\nyou will have to tailor it if they are located elsewhere on your system.\n\nTo limit Git accesses to repositories under '/gitroot' directory,\nmodify the '$1', as shown in the example below:\n\nrule git\nmatch $command ~ \"^git-(receive|upload)-pack\"\nset [1] =~ \"^/gitroot[^ ]+\\.git$\"\nset [0] =~ \"s|^|/usr/bin/|\"\n\nTo provide more helpful error messages, you may follow this rule by a\ntrap rule (*note trap rules: Exit.):\n\n# Trap the rest of Git requests:\nrule git-trap\nmatch $command ~ \"^git-.+\"\nexit \"fatal: access to this repository is denied.\"\n", "subsections": [] }, "File: rush.info, Node: notification example, Prev: git, Up: Usage Tips": { "content": "", "subsections": [ { "name": "6.7 Notification", "content": "" } ] }, "In this section we will show how to set up a mail notification for Rush": { "content": "rules. Let's suppose we wish to receive emails for each upload by\n'scp-to' rule (*note scp::). To do so, we add the following fall\nthrough rule to the beginning of 'rush.rc':\n\nrule default\npost-socket \"inet://localhost\"\nfall-trough\n\nThis will enable notifications for each rule located below this one.", "subsections": [] }, "Missing port in 'post-socket' statement means 'rush' will be using the": { "content": "default 'tcpmux' port.\n\nTo receive and process these requests, you will need an 'inetd'\ncapable to handle TCPMUX. We recommend the one from GNU Inetutils\npackage (GNU Inetutils (http://www.gnu.org/software/inetutils)). In\n'/etc/inetd.conf' file, we add:\n\n# Enable TCPMUX handling.\ntcpmux stream tcp nowait root internal\n# Handle 'scp-to' service.\ntcpmux/+scp-to stream tcp nowait root \\\n/usr/sbin/tcpd /bin/rushmail\n\nThe program '/bin/rushmail' does the actual notification. Following\nis its simplest implementation:\n\n#! /bin/sh\n\nread user command\n\n/usr/sbin/sendmail -oi -t <\nTo: \nSubject: GNU Rush notification\n\nBe informed that $user executed $command.\nEOT\n", "subsections": [] }, "File: rush.info, Node: Test Mode, Next: Option Summary, Prev: Usage Tips, Up: Top": { "content": "", "subsections": [] }, "7 Test Mode": { "content": "GNU Rush provides a special \"test mode\", intended to test configuration\nfiles and to emulate execution of commands. Test mode is enabled by the\n'--test' command line option (aliases: '--lint', '-t'). When 'rush' is\ngiven this option, the following occurs:\n\n1. All diagnostic messages are redirected to standard error, instead\nof syslog.\n\n2. If a single non-option argument is present, it is taken as a name\nof the configuration file to use.\n\n3. The configuration file is parsed. If parsing fails, the program\nexits with the code 1.\n\n4. If the '-c' option is present, 'rush' processes its argument as\nusual (*note Operation::), except that the command itself is not\nexecuted.\n\n5. Otherwise, if '-i' option is present, 'rush' emulates interactive\nusage, but does not execute the final command.\n\nAn exit status of 0 means no errors, 1 means an error has occurred.\n\nYou can also emulate access by a particular user, by supplying his\nuser name via the '--user' ('-u') option. This option implies '--test'.\n\nIn test mode, you can set debugging level (*note Debugging::) from\nthe command line, using the '--debug' ('-d') command line option. It\nexpects a single number specifying debugging level as its argument. The\ndebugging level set this way overrides settings from the configuration\nfile.\n\nHere are several examples that illustrate the use of test mode in\nvarious cases:\n\n1. Test default configuration file:\n\n$ rush --test\n\n2. Test configuration file 'sample.rc':\n\n$ rush --test sample.rc\n\n3. Test interactive access\n\n$ rush --test -i sample.rc\n\n4. Test the configuration file and emulate execution of the command\n'cvs server'. Use debugging level 2:\n\n$ rush --test --debug=2 -c \"cvs server\"\n\n5. Same, but for user 'jeff':\n\n$ rush --user=jeff --debug=2 -c \"cvs server\"\n\nNote, that you don't need to specify '--test' along with '--user'\nor '-i' options.\n\n6. Same, but use 'sample.rc' instead of the default configuration\nfile:\n\n$ rush --test --debug=2 -c \"cvs server\" sample.rc\n\n* Menu:\n\n* dump mode::\n", "subsections": [] }, "File: rush.info, Node: dump mode, Up: Test Mode": { "content": "", "subsections": [ { "name": "7.1 Dump Mode", "content": "" } ] }, "Dump mode is similar to test mode. The main difference is that in this": { "content": "mode, 'rush' dumps to the standard output a description of the user\nrequest after performing all checks and transformations.\n\nThe mode is requested by the '--dump=ATTR' ('-D ATTR') option. The\nargument ATTR is a comma-separated list of the names of attributes to be\nincluded in the dump, or the word 'all', standing for all attributes.\n\nAdditional options and arguments are the same as for the '--test'\noption.\n\nThe description is formatted as a JSON object(1) with the following\nattributes. These are also the allowed values for the ATTR list:\n\ncmdline\nCommand line after transformations.\n\nargv\nArray of command line arguments after transformations.\n\nprog\nName of the program to be executed. If 'null', 'argv[0]' will be\nused.\n\ninteractive\n'0' for normal requests, '1' for interactive requests.\n\npwname\nName of the user from the system user database.\n\npwuid\nUID of the user.\n\npwgid\nGID of the user.\n\npwdir\nHome directory of the user, as set in the system user database.\n\numask\nValue of the umask (octal).\n\nchrootdir\nChroot directory.\n\nhomedir\nCurrent working directory.\n\ngid\nNew GID as set by the 'newgrp' action, or '-1' if unchanged.\n\nfork\nFork mode. It is a three-state attribute: '0' meaning \"disabled\",\n'1' meaning \"enabled\", and '-1' meaning \"default state\".\n\nacct\nAccounting mode. See 'fork', for a description of possible values.\n\ntextdomain\nTextual domain for i18n.\n\nlocaledir\nLocale directory for i18n.\n\nlocale\nLocale name\n\nenviron\nDump of the environment (array of assignments).\n\nvars\nDefined variables, as a JSON object.\n\nThe attribute 'all' stands for all attribute in the same order as\nlisted in the table above.\n\n---------- Footnotes ----------\n\n(1) Well, almost. It diverges from the JSON standard in that slash\ncharacters are not escaped in string objects.\n", "subsections": [] }, "File: rush.info, Node: Option Summary, Next: Rushwho, Prev: Test Mode, Up: Top": { "content": "", "subsections": [] }, "8 Option Summary": { "content": "This chapter provides a short summary of 'rush' command line options.\n\n'-c COMMAND'\nSpecify the command to run.\n\n'-C TEST'\n'--security-check=TEST'\nConfigure security checks for the main configuration file. *Note\ninclude-security::, for the description of TEST argument. *Note\nsecurity checks::, for the discussion of the available security\ntests.\n\n'-d NUMBER'\n'--debug=NUMBER'\nSet debugging level.\n\n'--dump=ATTRS'\n'-D ATTRS'\nRun in \"request dump mode\". Argument is a comma-separated list of\nattribute names. *Note dump mode::, for a detailed description of\nthe request dump mode.\n\n'-i'\nEmulate interactive access. *Note Test Mode::.\n\n'--show-default'\nDisplay the default built-in configuration. *Note Default\nConfiguration::, for more information.\n\n'-t'\n'--test'\n'--lint'\nRun in test mode. An optional argument may be used with this\noption to specify alternative configuration file name, e.g.:\n\n$ rush --lint ./test.rc\n\nIf the '-c' option is also specified, 'rush' emulates the normal\nprocessing for the command, but does not execute it.\n\n'-x'\n'--trace'\nPrint parser traces. When used twice, print lexical scanner traces\nas well. This option is intended for debugging.\n\n'-T'\nTest scanner mode. This option is used by the 'rush' testsuite.\n\n'-u NAME'\n'--user=NAME'\nEmulate access by user NAME. This option implies '--test' and is\nvalid only when used by root and in conjunction with the '-c'\noption.\n\n'-v'\n'--version'\nDisplay program version.\n\n'-h'\n'--help'\nDisplay a short help message.\n\n'--usage'\nDisplay a concise usage summary.\n", "subsections": [] }, "File: rush.info, Node: Rushwho, Next: Rushlast, Prev: Option Summary, Up: Top": { "content": "", "subsections": [] }, "9 The 'rushwho' utility.": { "content": "", "subsections": [] }, "The 'rushwho' utility displays a list of users who are currently using": { "content": "'rush'. The utility operates on default Rush database, which is\nmaintained if 'rush' runs in accounting mode (*note Accounting and\nForked Mode::). The following is a sample output from 'rushwho':\n\nLogin Rule Start Time PID Command\njeff sftp Sun 12:17 00:58:26 10673 bin/sftp-server\n\nThe information displayed is:\n", "subsections": [] }, "Login": { "content": "The login name of the user.\n", "subsections": [] }, "Start": { "content": "Time when the command finished, or the word 'running' if it is\nstill running.\n", "subsections": [] }, "Time": { "content": "Duration of the session.\n", "subsections": [] }, "PID": { "content": "PID of the running command.\n", "subsections": [] }, "Command": { "content": "Command line being executed.\n\nThis format is a built-in default. It may be changed either by\nsetting the 'RUSHLASTFORMAT' environment variable to the desired format\nstring, or by using '--format' command line option (*note Rushlast\nOptions::).\n\n* Menu:\n\n* Rushlast Options::\n", "subsections": [] }, "File: rush.info, Node: Rushwho Options, Next: Formats, Up: Rushwho": { "content": "", "subsections": [ { "name": "9.1 Rushwho Options", "content": "" } ] }, "This section summarizes the command line options understood by 'rushwho'": { "content": "utility.\n\n'-F STRING'\n'--format=STRING'\nUse STRING instead of the default format, described in *note\nRushwho::. *Note Formats::, for a detailed description of the\noutput format syntax. If STRING begins with a '@', then this\ncharacter is removed from it, and the resulting string is treated\nas the name of the file to read. The contents of this file is the\nformat string. The file is read literally, except that lines\nbeginning with ';' are ignored (they can be used to introduce\ncomments). For example, 'rushwho --format=@formfile' reads in the\ncontents of the file named 'formfile'.\n\n'-f DIR'\n'--file=DIR'\nUse database directory DIR, instead of the default. By default,\ndatabase files are located in '/usr/local/var/rush'.\n\n'-H'\n'--no-header'\nDo not display header line.\n\n'-v'\n'--version'\nDisplay program version.\n\n'-h'\n'--help'\nDisplay a short help message.\n\n'--usage'\nDisplay a concise usage summary.\n", "subsections": [] }, "File: rush.info, Node: Formats, Prev: Rushwho Options, Up: Rushwho": { "content": "", "subsections": [ { "name": "9.2 Output Formats", "content": "A format string controls the output of every record from GNU Rush\naccounting database. It may contain following four types of objects:\n" } ] }, "Ordinary characters": { "content": "These are copied to the output verbatim.\n", "subsections": [] }, "Escapes": { "content": "An escape is a backslash ('\\\\'), followed by a single character.\nIt is interpreted as follows:\n\nEscape Output\n\\a Audible bell character (ASCII 7)\n\\b Backspace character (ASCII 8)\n\\e Escape character (ASCII 27)\n\\f Form-feed character (ASCII 12)\n\\n Newline character (ASCII 10)\n\\r Carriage return character (ASCII\n13)\n\\t Horizontal tabulation character\n(ASCII 9)\n\\v Vertical tabulation character\n(ASCII 11)\n\\\\ A single backslash ('\\')\n\\\" A double-quote.\n\nAny escape not listed in the table above results in its second\ncharacter being output.\n", "subsections": [] }, "Quoted strings": { "content": "Strings are delimited by single or double quotes. Within a string\nescape sequences are interpreted as described above.\n", "subsections": [] }, "Format specifications": { "content": "A \"format specification\" is a kind of function, which outputs a\nparticular piece of information from the database record.\n\nEach format specification starts with an opening brace and ends with\na closing brace. The first word after the brace is the name of the\nformat specification. Remaining words are \"positional arguments\"\nfollowed by \"keyword arguments\". Both are optional. When specified,\nkeyword arguments must follow positional ones. A keyword argument\nbegins with a colon. For example:\n\n'(time)'\nA single format specification.\n\n'(time 10)'\nThe same format specification with the output width limited to 10\ncharacters.\n\n'(time 10 Duration)'\nThe 'time' format specification, with the output width limited to\n10 characters and 'Duration' as a header title.\n\n'(time 10 \"Session Duration\" :right :format %H:%M)'\nThe same with two keyword arguments: ':right' and ':format'. The\nlatter takes the string '%H:%M' as its argument. Notice the use of\nquoted string to preserve the whitespace.\n\nA full list of format specifications follows.\n\n-- Format Spec: newline [COUNT]\nCauses the newline character to be output. If the optional COUNT\nis supplied, that many newlines will be printed\n\n-- Format Spec: tab [NUM]\nAdvance to the next tab stop in the output stream. If optional NUM\nis present, then skip NUM tab stops. Each tab stop is eight\ncharacters long.\n\nThe following specifications output particular fields from the\ndatabase record. They all take two positional arguments: WIDTH and\nTITLE.\n\nThe first argument, WIDTH sets the maximum output length for this\nspecification. If the number of characters actually output is less than\nthe width, they will be padded with whitespace either to the left or to\nthe right, depending on the presence of the ':right' keyword argument.", "subsections": [] }, "If the number of characters is greater than WIDTH, they will be": { "content": "truncated to fit. If WIDTH is not given, the field is output as is.\n\nThe second argument, TITLE, gives the title of this column for the\nheading line. By default no title is output.\n\nEvery field specification accepts at least two keyword arguments.\nThe keyword ':right' may be used to request alignment to the right.\nThis keyword is ignored if WIDTH is not given.\n\nThe keyword ':empty' followed by a string instructs 'rushwho' to\noutput that string if the resulting value for this specification would\notherwise be empty.\n\n-- Format Spec: user WIDTH TITLE [:empty REPL][:right]\nPrint the user login name.\n\n-- Format Spec: time WIDTH TITLE [:empty REPL] [:right] [:format\nDATE-FORMAT]\n-- Format Spec: start-time WIDTH TITLE [:empty REPL] [:right] [:format\nDATE-FORMAT]\n\nDate and time when the session started.\n\nThe ':format' keyword introduces the 'strftime' format string to be\nused when converting the date for printing. The default value is\n'%a %H:%M'. *Note Time and Date Formats::, for a detailed\ndescription of 'strftime' format strings.\n\n-- Format Spec: stop-time WIDTH TITLE [:empty REPL] [:right] [:format\nDATE-FORMAT]\nTime when the command finished. This specifier is meaningful only\nfor 'rushlast' (*note Rushlast::). If the command is still\nrunning, the word 'running' is output.\n\n-- Format Spec: duration WIDTH TITLE [:empty REPL] [:right]\nTotal time of the session duration.\n\n-- Format Spec: rule WIDTH TITLE [:right]\nThe tag of the rule used to serve the user. *Note tag: Rule, for a\ndetailed description of rules and tags.\n\n-- Format Spec: command WIDTH TITLE [:empty REPL] [:right]\nCommand line being executed.\n\n-- Format Spec: pid WIDTH TITLE [:right]\nPID of the process.\n\nFor example, the following is the default format for the 'rushwho'\nutility. It is written in a form suitable for use in a file supplied\nwith the '--format=@FILE' command line option (*note format option::):\n\n(user 10 Login)\" \"\n(rule 8 Rule)\" \"\n(start-time 0 Start)\" \"\n(duration 9 Time)\" \"\n(pid 10 PID)\" \"\n(command 28 Command)\n", "subsections": [] }, "File: rush.info, Node: Rushlast, Next: Accounting Database, Prev: Rushwho, Up: Top": { "content": "", "subsections": [] }, "10 The 'rushlast' utility.": { "content": "", "subsections": [] }, "The 'rushlast' utility searches back through the GNU Rush database and": { "content": "displays a list of all user sessions since the database was created. By\ndefault, it displays the following information:\n\nLogin Rule Start Stop Time Command\ngray rsync Sun 20:43 Sun 20:43 05:57 /usr/bin/rsync /upload\njeff sftp Sun 20:09 running 07:17 /bin/sftp-server\n", "subsections": [] }, "File: rush.info, Node: Rushlast Options, Up: Rushlast": { "content": "", "subsections": [ { "name": "10.1 Rushlast Options", "content": "" } ] }, "This section summarizes the command line options understood by": { "content": "'rushlast' utility.\n\n'-F STRING'\n'--format=STRING'\nUse STRING instead of the default format, described in *note\nRushwho::. *Note Formats::, for a detailed description of the\noutput format syntax. To read format from a file, use\n'--format=@FILENAME'. The file is read literally, except that\nlines beginning with ';' are ignored (they can be used to introduce\ncomments).\n\n'-f DIR'\n'--file=DIR'\nUse database directory DIR, instead of the default. By default,\ndatabase files are located in '/usr/local/var/rush'.\n\n'--forward'\nDisplay entries in chronological order, instead of the reverse\nchronological one, which is the default.\n\n'-n NUMBER'\n'--count=NUMBER'\n'-NUMBER'\nShow at most NUMBER records. The form '-NUMBER' is provided for\ncompatibility with the 'last(1)' utility.\n\n'-H'\n'--no-header'\nDo not display header line.\n\n'-v'\n'--version'\nDisplay program version.\n\n'-h'\n'--help'\nDisplay a short help message.\n\n'--usage'\nDisplay a concise usage summary.\n", "subsections": [] }, "File: rush.info, Node: Accounting Database, Next: Reporting Bugs, Prev: Rushlast, Up: Top": { "content": "", "subsections": [] }, "11 Accounting Database": { "content": "", "subsections": [] }, "Rush accounting database is stored in the directory": { "content": "'LOCALSTATEDIR/rush', where LOCALSTATEDIR stands for the name of the\nlocal state directory, defined at compile time. By default, it is\n'PREFIX/var', where PREFIX is the installation prefix, which defaults to\n'/usr/local'. Thus, the default database directory is\n'/usr/local/var/rush'. You can change this default using the\n'--localstatedir' option to 'configure' before compiling the package.\nThe '--prefix' option affects it as well.\n\nAs of version 2.3, the database consists of two files, called 'utmp'\nand 'wtmp'. The 'wtmp' file keeps information about all user sessions,\nboth finished and still active. The 'utmp' file contains indices to\nthose records in 'wtmp', which represent active sessions.\n\nThe 'wtmp' grows continuously, while 'utmp' normally grows the first\nday or two after enabling accounting mode, and from then on its size\nremains without changes. If you set up log file rotation, e.g. by\nusing 'logrotate' (*note logrotate: (logrotate(8))logrotate.), or a\nsimilar tool, it is safe to rotate 'wtmp' without notifying 'rush'. The\nonly requirement is to truncate 'utmp' to zero size after rotating\n'wtmp', as shown in the following 'logrotate.conf' snippet:\n\n/var/run/rush/wtmp {\nmonthly\ncreate 0640 root svusers\npostrotate\ncat /dev/null > /var/run/rush/utmp\nendscript\n}\n\nAccounting files are owned by 'root' and normally are accessible only\nto the owner (file mode '600'). You may change the default permissions\nusing the following global configuration file statements:\n\n-- global: acct-umask MASK\nSet umask used when accessing accounting database files. Default\nvalue is '022'.\n\n-- global: acct-dir-mode MODE\nSet mode bits for the accounting directory. The MODE argument is\nthe mode in octal.\n\n-- global: acct-file-mode MODE\nSet mode bits for 'wtmp' and 'utmp' files.\n\nNotice, that these statements affect file and directory modes only\nwhen the corresponding file or directory is created. 'Rush' will not\nchange modes of the existing files.\n\nThe following sections contain a detailed description of the\nstructure of these two files. You may skip them, if you are not\ninterested in technical details.\n\n* Menu:\n\n* wtmp:: The Structure of 'wtmp' File.\n* utmp:: The Structure of 'wtmp' File.\n", "subsections": [] }, "File: rush.info, Node: wtmp, Next: utmp, Up: Accounting Database": { "content": "", "subsections": [ { "name": "11.1 The 'wtmp' file", "content": "" } ] }, "The 'wtmp' file consists of variable-size entries. It is designed so": { "content": "that it can easily be read in both directions.\n\nEach record begins with a fixed-size header, which is followed by\nthree zero-terminated strings, and the record size in 'sizet'\nrepresentation. The three strings are, in that order: the user login\nname, the rule tag, and the full command line.\n\nThe header has the following structure:\n\nstruct rushwtmp {\nsizet reclen;\npidt pid;\nstruct timeval start;\nstruct timeval stop;\nchar *unused[3];\n};\n\nwhere:\n\n'reclen'\nis the length of the entire record, including the size of this\nheader. This field is duplicated at the end of the record.\n\n'pid'\nis the PID of the command executed for the user.\n\n'start'\nrepresents the time of the beginning of the user session.\n\n'stop'\nrepresents the time when the user session finished. If the session\nis still running, this field is filled with zeros.\n\n'unused'\nThe three pointers at the end of the structure are used internally\nby 'rush'. On disk, these fields are always filled with zeros.\n", "subsections": [] }, "File: rush.info, Node: utmp, Prev: wtmp, Up: Accounting Database": { "content": "", "subsections": [ { "name": "11.2 The 'utmp' file", "content": "" } ] }, "The 'utmp' file consists of a fixed-size records of the following": { "content": "structure:\n\nstruct rushutmp {\nint status;\nofft offset;\n};\n\nThe fields have the following meaning:\n\n'status'\nStatus of the record: '0' if the record is unused, and '1' if it\nrepresents an active session.\n\n'offset'\nOffset of the corresponding record in 'wtmp' (see previous\nsection).\n", "subsections": [] }, "File: rush.info, Node: Reporting Bugs, Next: Time and Date Formats, Prev: Accounting Database, Up: Top": { "content": "", "subsections": [] }, "12 How to Report a Bug": { "content": "Email bug reports to . Please include a detailed\ndescription of the bug and information about the conditions under which\nit occurs, so we can reproduce it. To facilitate the task, the\nfollowing list shows the basic set of information that is needed in\norder to find the bug:\n\n* Package version you use.\n* A detailed description of the bug.\n* Conditions under which the bug appears.\n* It is often helpful to send the contents of 'config.log' file along\nwith your bug report. This file is created after running\n'./configure' in the GNU Rush source root directory.\n", "subsections": [] }, "File: rush.info, Node: Time and Date Formats, Next: Copying This Manual, Prev: Reporting Bugs, Up: Top": { "content": "", "subsections": [] }, "Appendix A Time and Date Formats": { "content": "", "subsections": [] }, "This appendix documents the time format specifications understood by the": { "content": "':format' keyword in time output format specifiers (*note Formats::).", "subsections": [] }, "Essentially, it is a reproduction of the man page for GNU 'strftime'": { "content": "function.\n\nOrdinary characters placed in the format string are reproduced\nwithout conversion. Conversion specifiers are introduced by a '%'\ncharacter, and are replaced as follows:\n\n%a The abbreviated weekday name according to the\ncurrent locale.\n\n%A The full weekday name according to the current\nlocale.\n\n%b The abbreviated month name according to the\ncurrent locale.\n\n%B The full month name according to the current\nlocale.\n\n\n%c The preferred date and time representation for\nthe current locale.\n\n%C The century number (year/100) as a 2-digit\ninteger.\n\n%d The day of the month as a decimal number (range\n01 to 31).\n\n%D Equivalent to '%m/%d/%y'.\n\n%e Like '%d', the day of the month as a decimal\nnumber, but a leading zero is replaced by a\nspace.\n\n%E Modifier: use alternative format, see below\n(*note conversion specs::).\n\n%F Equivalent to '%Y-%m-%d' (the ISO 8601 date\nformat).\n\n%G The ISO 8601 year with century as a decimal\nnumber. The 4-digit year corresponding to the\nISO week number (see '%V'). This has the same\nformat and value as '%y', except that if the ISO\nweek number belongs to the previous or next\nyear, that year is used instead.\n\n%g Like '%G', but without century, i.e., with a\n2-digit year (00-99).\n\n%h Equivalent to '%b'.\n\n%H The hour as a decimal number using a 24-hour\nclock (range 00 to 23).\n\n%I The hour as a decimal number using a 12-hour\nclock (range 01 to 12).\n\n%j The day of the year as a decimal number (range\n001 to 366).\n\n%k The hour (24-hour clock) as a decimal number\n(range 0 to 23); single digits are preceded by a\nblank. (See also '%H'.)\n\n%l The hour (12-hour clock) as a decimal number\n(range 1 to 12); single digits are preceded by a\nblank. (See also '%I'.)\n\n%m The month as a decimal number (range 01 to 12).\n\n%M The minute as a decimal number (range 00 to 59).\n\n%n A newline character.\n\n%O Modifier: use alternative format, see below\n(*note conversion specs::).\n\n%p Either 'AM' or 'PM' according to the given time\nvalue, or the corresponding strings for the\ncurrent locale. Noon is treated as 'pm' and\nmidnight as 'am'.\n\n%P Like '%p' but in lowercase: 'am' or 'pm' or a\ncorresponding string for the current locale.\n\n%r The time in 'a.m.' or 'p.m.' notation. In the\nPOSIX locale this is equivalent to '%I:%M:%S\n%p'.\n\n%R The time in 24-hour notation ('%H:%M'). For a\nversion including the seconds, see '%T' below.\n\n\n%s The number of seconds since the Epoch, i.e.,\nsince 1970-01-01 00:00:00 UTC.\n\n%S The second as a decimal number (range 00 to 61).\n\n%t A tab character.\n\n%T The time in 24-hour notation ('%H:%M:%S').\n\n%u The day of the week as a decimal, range 1 to 7,\nMonday being 1. See also '%w'.\n\n%U The week number of the current year as a decimal\nnumber, range 00 to 53, starting with the first\nSunday as the first day of week 01. See also\n'%V' and '%W'.\n\n%V The ISO 8601:1988 week number of the current\nyear as a decimal number, range 01 to 53, where\nweek 1 is the first week that has at least 4\ndays in the current year, and with Monday as the\nfirst day of the week. See also '%U' and '%W'.\n\n%w The day of the week as a decimal, range 0 to 6,\nSunday being 0. See also '%u'.\n\n%W The week number of the current year as a decimal\nnumber, range 00 to 53, starting with the first\nMonday as the first day of week 01.\n\n%x The preferred date representation for the\ncurrent locale without the time.\n\n%X The preferred time representation for the\ncurrent locale without the date.\n\n%y The year as a decimal number without a century\n(range 00 to 99).\n\n%Y The year as a decimal number including the\ncentury.\n\n%z The time-zone as hour offset from GMT. Required\nto emit RFC822-conformant dates (using '%a, %d\n%b %Y %H:%M:%S %z')\n\n%Z The time zone or name or abbreviation.\n\n%+ The date and time in 'date(1)' format.\n\n%% A literal '%' character.\n\nSome conversion specifiers can be modified by preceding them by the\n'E' or 'O' modifier to indicate that an alternative format should be\nused. If the alternative format or specification does not exist for the\ncurrent locale, the behaviour will be as if the unmodified conversion\nspecification were used. The Single Unix Specification mentions '%Ec',\n'%EC', '%Ex', '%EX', '%Ry', '%EY', '%Od', '%Oe', '%OH', '%OI', '%Om',\n'%OM', '%OS', '%Ou', '%OU', '%OV', '%Ow', '%OW', '%Oy', where the effect\nof the 'O' modifier is to use alternative numeric symbols (say, roman\nnumerals), and that of the 'E' modifier is to use a locale-dependent\nalternative representation.\n", "subsections": [] }, "File: rush.info, Node: Copying This Manual, Next: Concept Index, Prev: Time and Date Formats, Up: Top": { "content": "", "subsections": [] }, "Appendix B GNU Free Documentation License": { "content": "Version 1.3, 3 November 2008\n\nCopyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.\n\n\nEveryone is permitted to copy and distribute verbatim copies\nof this license document, but changing it is not allowed.\n\n0. PREAMBLE\n\nThe purpose of this License is to make a manual, textbook, or other\nfunctional and useful document \"free\" in the sense of freedom: to\nassure everyone the effective freedom to copy and redistribute it,\nwith or without modifying it, either commercially or\nnoncommercially. Secondarily, this License preserves for the\nauthor and publisher a way to get credit for their work, while not\nbeing considered responsible for modifications made by others.\n\nThis License is a kind of \"copyleft\", which means that derivative\nworks of the document must themselves be free in the same sense.\nIt complements the GNU General Public License, which is a copyleft\nlicense designed for free software.\n\nWe have designed this License in order to use it for manuals for\nfree software, because free software needs free documentation: a\nfree program should come with manuals providing the same freedoms\nthat the software does. But this License is not limited to\nsoftware manuals; it can be used for any textual work, regardless\nof subject matter or whether it is published as a printed book. We\nrecommend this License principally for works whose purpose is\ninstruction or reference.\n\n1. APPLICABILITY AND DEFINITIONS\n\nThis License applies to any manual or other work, in any medium,\nthat contains a notice placed by the copyright holder saying it can\nbe distributed under the terms of this License. Such a notice\ngrants a world-wide, royalty-free license, unlimited in duration,\nto use that work under the conditions stated herein. The\n\"Document\", below, refers to any such manual or work. Any member\nof the public is a licensee, and is addressed as \"you\". You accept\nthe license if you copy, modify or distribute the work in a way\nrequiring permission under copyright law.\n\nA \"Modified Version\" of the Document means any work containing the\nDocument or a portion of it, either copied verbatim, or with\nmodifications and/or translated into another language.\n\nA \"Secondary Section\" is a named appendix or a front-matter section\nof the Document that deals exclusively with the relationship of the\npublishers or authors of the Document to the Document's overall\nsubject (or to related matters) and contains nothing that could\nfall directly within that overall subject. (Thus, if the Document\nis in part a textbook of mathematics, a Secondary Section may not\nexplain any mathematics.) The relationship could be a matter of\nhistorical connection with the subject or with related matters, or\nof legal, commercial, philosophical, ethical or political position\nregarding them.\n\nThe \"Invariant Sections\" are certain Secondary Sections whose\ntitles are designated, as being those of Invariant Sections, in the\nnotice that says that the Document is released under this License.\nIf a section does not fit the above definition of Secondary then it\nis not allowed to be designated as Invariant. The Document may\ncontain zero Invariant Sections. If the Document does not identify\nany Invariant Sections then there are none.\n\nThe \"Cover Texts\" are certain short passages of text that are\nlisted, as Front-Cover Texts or Back-Cover Texts, in the notice\nthat says that the Document is released under this License. A\nFront-Cover Text may be at most 5 words, and a Back-Cover Text may\nbe at most 25 words.\n\nA \"Transparent\" copy of the Document means a machine-readable copy,\nrepresented in a format whose specification is available to the\ngeneral public, that is suitable for revising the document\nstraightforwardly with generic text editors or (for images composed\nof pixels) generic paint programs or (for drawings) some widely\navailable drawing editor, and that is suitable for input to text\nformatters or for automatic translation to a variety of formats\nsuitable for input to text formatters. A copy made in an otherwise\nTransparent file format whose markup, or absence of markup, has\nbeen arranged to thwart or discourage subsequent modification by\nreaders is not Transparent. An image format is not Transparent if\nused for any substantial amount of text. A copy that is not\n\"Transparent\" is called \"Opaque\".\n\nExamples of suitable formats for Transparent copies include plain\nASCII without markup, Texinfo input format, LaTeX input format,\nSGML or XML using a publicly available DTD, and standard-conforming\nsimple HTML, PostScript or PDF designed for human modification.\nExamples of transparent image formats include PNG, XCF and JPG.\nOpaque formats include proprietary formats that can be read and\nedited only by proprietary word processors, SGML or XML for which\nthe DTD and/or processing tools are not generally available, and\nthe machine-generated HTML, PostScript or PDF produced by some word\nprocessors for output purposes only.\n\nThe \"Title Page\" means, for a printed book, the title page itself,\nplus such following pages as are needed to hold, legibly, the\nmaterial this License requires to appear in the title page. For\nworks in formats which do not have any title page as such, \"Title\nPage\" means the text near the most prominent appearance of the\nwork's title, preceding the beginning of the body of the text.\n\nThe \"publisher\" means any person or entity that distributes copies\nof the Document to the public.\n\nA section \"Entitled XYZ\" means a named subunit of the Document\nwhose title either is precisely XYZ or contains XYZ in parentheses\nfollowing text that translates XYZ in another language. (Here XYZ\nstands for a specific section name mentioned below, such as\n\"Acknowledgements\", \"Dedications\", \"Endorsements\", or \"History\".)\nTo \"Preserve the Title\" of such a section when you modify the\nDocument means that it remains a section \"Entitled XYZ\" according\nto this definition.\n\nThe Document may include Warranty Disclaimers next to the notice\nwhich states that this License applies to the Document. These\nWarranty Disclaimers are considered to be included by reference in\nthis License, but only as regards disclaiming warranties: any other\nimplication that these Warranty Disclaimers may have is void and\nhas no effect on the meaning of this License.\n\n2. VERBATIM COPYING\n\nYou may copy and distribute the Document in any medium, either\ncommercially or noncommercially, provided that this License, the\ncopyright notices, and the license notice saying this License\napplies to the Document are reproduced in all copies, and that you\nadd no other conditions whatsoever to those of this License. You\nmay not use technical measures to obstruct or control the reading\nor further copying of the copies you make or distribute. However,\nyou may accept compensation in exchange for copies. If you\ndistribute a large enough number of copies you must also follow the\nconditions in section 3.\n\nYou may also lend copies, under the same conditions stated above,\nand you may publicly display copies.\n\n3. COPYING IN QUANTITY\n\nIf you publish printed copies (or copies in media that commonly\nhave printed covers) of the Document, numbering more than 100, and\nthe Document's license notice requires Cover Texts, you must\nenclose the copies in covers that carry, clearly and legibly, all\nthese Cover Texts: Front-Cover Texts on the front cover, and\nBack-Cover Texts on the back cover. Both covers must also clearly\nand legibly identify you as the publisher of these copies. The\nfront cover must present the full title with all words of the title\nequally prominent and visible. You may add other material on the\ncovers in addition. Copying with changes limited to the covers, as\nlong as they preserve the title of the Document and satisfy these\nconditions, can be treated as verbatim copying in other respects.\n\nIf the required texts for either cover are too voluminous to fit\nlegibly, you should put the first ones listed (as many as fit\nreasonably) on the actual cover, and continue the rest onto\nadjacent pages.\n\nIf you publish or distribute Opaque copies of the Document\nnumbering more than 100, you must either include a machine-readable\nTransparent copy along with each Opaque copy, or state in or with\neach Opaque copy a computer-network location from which the general\nnetwork-using public has access to download using public-standard\nnetwork protocols a complete Transparent copy of the Document, free\nof added material. If you use the latter option, you must take\nreasonably prudent steps, when you begin distribution of Opaque\ncopies in quantity, to ensure that this Transparent copy will\nremain thus accessible at the stated location until at least one\nyear after the last time you distribute an Opaque copy (directly or\nthrough your agents or retailers) of that edition to the public.\n\nIt is requested, but not required, that you contact the authors of\nthe Document well before redistributing any large number of copies,\nto give them a chance to provide you with an updated version of the\nDocument.\n\n4. MODIFICATIONS\n\nYou may copy and distribute a Modified Version of the Document\nunder the conditions of sections 2 and 3 above, provided that you\nrelease the Modified Version under precisely this License, with the\nModified Version filling the role of the Document, thus licensing\ndistribution and modification of the Modified Version to whoever\npossesses a copy of it. In addition, you must do these things in\nthe Modified Version:\n\nA. Use in the Title Page (and on the covers, if any) a title\ndistinct from that of the Document, and from those of previous\nversions (which should, if there were any, be listed in the\nHistory section of the Document). You may use the same title\nas a previous version if the original publisher of that\nversion gives permission.\n\nB. List on the Title Page, as authors, one or more persons or\nentities responsible for authorship of the modifications in\nthe Modified Version, together with at least five of the\nprincipal authors of the Document (all of its principal\nauthors, if it has fewer than five), unless they release you\nfrom this requirement.\n\nC. State on the Title page the name of the publisher of the\nModified Version, as the publisher.\n\nD. Preserve all the copyright notices of the Document.\n\nE. Add an appropriate copyright notice for your modifications\nadjacent to the other copyright notices.\n\nF. Include, immediately after the copyright notices, a license\nnotice giving the public permission to use the Modified\nVersion under the terms of this License, in the form shown in\nthe Addendum below.\n\nG. Preserve in that license notice the full lists of Invariant\nSections and required Cover Texts given in the Document's\nlicense notice.\n\nH. Include an unaltered copy of this License.\n\nI. Preserve the section Entitled \"History\", Preserve its Title,\nand add to it an item stating at least the title, year, new\nauthors, and publisher of the Modified Version as given on the\nTitle Page. If there is no section Entitled \"History\" in the\nDocument, create one stating the title, year, authors, and\npublisher of the Document as given on its Title Page, then add\nan item describing the Modified Version as stated in the\nprevious sentence.\n\nJ. Preserve the network location, if any, given in the Document\nfor public access to a Transparent copy of the Document, and\nlikewise the network locations given in the Document for\nprevious versions it was based on. These may be placed in the\n\"History\" section. You may omit a network location for a work\nthat was published at least four years before the Document\nitself, or if the original publisher of the version it refers\nto gives permission.\n\nK. For any section Entitled \"Acknowledgements\" or \"Dedications\",\nPreserve the Title of the section, and preserve in the section\nall the substance and tone of each of the contributor\nacknowledgements and/or dedications given therein.\n\nL. Preserve all the Invariant Sections of the Document, unaltered\nin their text and in their titles. Section numbers or the\nequivalent are not considered part of the section titles.\n\nM. Delete any section Entitled \"Endorsements\". Such a section\nmay not be included in the Modified Version.\n\nN. Do not retitle any existing section to be Entitled\n\"Endorsements\" or to conflict in title with any Invariant\nSection.\n\nO. Preserve any Warranty Disclaimers.\n\nIf the Modified Version includes new front-matter sections or\nappendices that qualify as Secondary Sections and contain no\nmaterial copied from the Document, you may at your option designate\nsome or all of these sections as invariant. To do this, add their\ntitles to the list of Invariant Sections in the Modified Version's\nlicense notice. These titles must be distinct from any other\nsection titles.\n\nYou may add a section Entitled \"Endorsements\", provided it contains\nnothing but endorsements of your Modified Version by various\nparties--for example, statements of peer review or that the text\nhas been approved by an organization as the authoritative\ndefinition of a standard.\n\nYou may add a passage of up to five words as a Front-Cover Text,\nand a passage of up to 25 words as a Back-Cover Text, to the end of\nthe list of Cover Texts in the Modified Version. Only one passage\nof Front-Cover Text and one of Back-Cover Text may be added by (or\nthrough arrangements made by) any one entity. If the Document\nalready includes a cover text for the same cover, previously added\nby you or by arrangement made by the same entity you are acting on\nbehalf of, you may not add another; but you may replace the old\none, on explicit permission from the previous publisher that added\nthe old one.\n\nThe author(s) and publisher(s) of the Document do not by this\nLicense give permission to use their names for publicity for or to\nassert or imply endorsement of any Modified Version.\n\n5. COMBINING DOCUMENTS\n\nYou may combine the Document with other documents released under\nthis License, under the terms defined in section 4 above for\nmodified versions, provided that you include in the combination all\nof the Invariant Sections of all of the original documents,\nunmodified, and list them all as Invariant Sections of your\ncombined work in its license notice, and that you preserve all\ntheir Warranty Disclaimers.\n\nThe combined work need only contain one copy of this License, and\nmultiple identical Invariant Sections may be replaced with a single\ncopy. If there are multiple Invariant Sections with the same name\nbut different contents, make the title of each such section unique\nby adding at the end of it, in parentheses, the name of the\noriginal author or publisher of that section if known, or else a\nunique number. Make the same adjustment to the section titles in\nthe list of Invariant Sections in the license notice of the\ncombined work.\n\nIn the combination, you must combine any sections Entitled\n\"History\" in the various original documents, forming one section\nEntitled \"History\"; likewise combine any sections Entitled\n\"Acknowledgements\", and any sections Entitled \"Dedications\". You\nmust delete all sections Entitled \"Endorsements.\"\n\n6. COLLECTIONS OF DOCUMENTS\n\nYou may make a collection consisting of the Document and other\ndocuments released under this License, and replace the individual\ncopies of this License in the various documents with a single copy\nthat is included in the collection, provided that you follow the\nrules of this License for verbatim copying of each of the documents\nin all other respects.\n\nYou may extract a single document from such a collection, and\ndistribute it individually under this License, provided you insert\na copy of this License into the extracted document, and follow this\nLicense in all other respects regarding verbatim copying of that\ndocument.\n\n7. AGGREGATION WITH INDEPENDENT WORKS\n\nA compilation of the Document or its derivatives with other\nseparate and independent documents or works, in or on a volume of a\nstorage or distribution medium, is called an \"aggregate\" if the\ncopyright resulting from the compilation is not used to limit the\nlegal rights of the compilation's users beyond what the individual\nworks permit. When the Document is included in an aggregate, this\nLicense does not apply to the other works in the aggregate which\nare not themselves derivative works of the Document.\n\nIf the Cover Text requirement of section 3 is applicable to these\ncopies of the Document, then if the Document is less than one half\nof the entire aggregate, the Document's Cover Texts may be placed\non covers that bracket the Document within the aggregate, or the\nelectronic equivalent of covers if the Document is in electronic\nform. Otherwise they must appear on printed covers that bracket\nthe whole aggregate.\n\n8. TRANSLATION\n\nTranslation is considered a kind of modification, so you may\ndistribute translations of the Document under the terms of section\n4. Replacing Invariant Sections with translations requires special\npermission from their copyright holders, but you may include\ntranslations of some or all Invariant Sections in addition to the\noriginal versions of these Invariant Sections. You may include a\ntranslation of this License, and all the license notices in the\nDocument, and any Warranty Disclaimers, provided that you also\ninclude the original English version of this License and the\noriginal versions of those notices and disclaimers. In case of a\ndisagreement between the translation and the original version of\nthis License or a notice or disclaimer, the original version will\nprevail.\n\nIf a section in the Document is Entitled \"Acknowledgements\",\n\"Dedications\", or \"History\", the requirement (section 4) to\nPreserve its Title (section 1) will typically require changing the\nactual title.\n\n9. TERMINATION\n\nYou may not copy, modify, sublicense, or distribute the Document\nexcept as expressly provided under this License. Any attempt\notherwise to copy, modify, sublicense, or distribute it is void,\nand will automatically terminate your rights under this License.\n\nHowever, if you cease all violation of this License, then your\nlicense from a particular copyright holder is reinstated (a)\nprovisionally, unless and until the copyright holder explicitly and\nfinally terminates your license, and (b) permanently, if the\ncopyright holder fails to notify you of the violation by some\nreasonable means prior to 60 days after the cessation.\n\nMoreover, your license from a particular copyright holder is\nreinstated permanently if the copyright holder notifies you of the\nviolation by some reasonable means, this is the first time you have\nreceived notice of violation of this License (for any work) from\nthat copyright holder, and you cure the violation prior to 30 days\nafter your receipt of the notice.\n\nTermination of your rights under this section does not terminate\nthe licenses of parties who have received copies or rights from you\nunder this License. If your rights have been terminated and not\npermanently reinstated, receipt of a copy of some or all of the\nsame material does not give you any rights to use it.\n\n10. FUTURE REVISIONS OF THIS LICENSE\n\nThe Free Software Foundation may publish new, revised versions of\nthe GNU Free Documentation License from time to time. Such new\nversions will be similar in spirit to the present version, but may\ndiffer in detail to address new problems or concerns. See\n.\n\nEach version of the License is given a distinguishing version\nnumber. If the Document specifies that a particular numbered\nversion of this License \"or any later version\" applies to it, you\nhave the option of following the terms and conditions either of\nthat specified version or of any later version that has been\npublished (not as a draft) by the Free Software Foundation. If the\nDocument does not specify a version number of this License, you may\nchoose any version ever published (not as a draft) by the Free\nSoftware Foundation. If the Document specifies that a proxy can\ndecide which future versions of this License can be used, that\nproxy's public statement of acceptance of a version permanently\nauthorizes you to choose that version for the Document.\n\n11. RELICENSING\n\n\"Massive Multiauthor Collaboration Site\" (or \"MMC Site\") means any\nWorld Wide Web server that publishes copyrightable works and also\nprovides prominent facilities for anybody to edit those works. A\npublic wiki that anybody can edit is an example of such a server.\nA \"Massive Multiauthor Collaboration\" (or \"MMC\") contained in the\nsite means any set of copyrightable works thus published on the MMC\nsite.\n\n\"CC-BY-SA\" means the Creative Commons Attribution-Share Alike 3.0\nlicense published by Creative Commons Corporation, a not-for-profit\ncorporation with a principal place of business in San Francisco,\nCalifornia, as well as future copyleft versions of that license\npublished by that same organization.\n\n\"Incorporate\" means to publish or republish a Document, in whole or\nin part, as part of another Document.\n\nAn MMC is \"eligible for relicensing\" if it is licensed under this\nLicense, and if all works that were first published under this\nLicense somewhere other than this MMC, and subsequently\nincorporated in whole or in part into the MMC, (1) had no cover\ntexts or invariant sections, and (2) were thus incorporated prior\nto November 1, 2008.\n\nThe operator of an MMC Site may republish an MMC contained in the\nsite under CC-BY-SA on the same site at any time before August 1,\n2009, provided the MMC is eligible for relicensing.\n", "subsections": [ { "name": "ADDENDUM: How to use this License for your documents", "content": "" } ] }, "To use this License in a document you have written, include a copy of": { "content": "the License in the document and put the following copyright and license\nnotices just after the title page:\n\nCopyright (C) YEAR YOUR NAME.\nPermission is granted to copy, distribute and/or modify this document\nunder the terms of the GNU Free Documentation License, Version 1.3\nor any later version published by the Free Software Foundation;\nwith no Invariant Sections, no Front-Cover Texts, and no Back-Cover\nTexts. A copy of the license is included in the section entitled ``GNU\nFree Documentation License''.\n\nIf you have Invariant Sections, Front-Cover Texts and Back-Cover\nTexts, replace the \"with...Texts.\" line with this:\n\nwith the Invariant Sections being LIST THEIR TITLES, with\nthe Front-Cover Texts being LIST, and with the Back-Cover Texts\nbeing LIST.\n\nIf you have Invariant Sections without Cover Texts, or some other\ncombination of the three, merge those two alternatives to suit the\nsituation.\n\nIf your document contains nontrivial examples of program code, we\nrecommend releasing these examples in parallel under your choice of free\nsoftware license, such as the GNU General Public License, to permit\ntheir use in free software.\n", "subsections": [] }, "File: rush.info, Node: Concept Index, Prev: Copying This Manual, Up: Top": { "content": "", "subsections": [] }, "Concept Index": { "content": "This is a general index of all issues discussed in this manual.\n\n\n* Menu:\n\n* $#: Request variables. (line 18)\n* --count, rushlast: Rushlast Options. (line 27)\n* --debug: Test Mode. (line 32)\n* --debug, rush: Option Summary. (line 18)\n* --dump: dump mode. (line 10)\n* --dump <1>: Option Summary. (line 22)\n* --file, rushlast: Rushlast Options. (line 18)\n* --file, rushwho: Rushwho Options. (line 21)\n* --format, rushlast: Rushlast Options. (line 9)\n* --format, rushwho: Rushwho Options. (line 9)\n* --forward, rushlast: Rushlast Options. (line 23)\n* --help, rush: Option Summary. (line 64)\n* --help, rushlast: Rushlast Options. (line 41)\n* --help, rushwho: Rushwho Options. (line 34)\n* --lint: Test Mode. (line 6)\n* --lint, rush: Option Summary. (line 35)\n* --no-header, rushlast: Rushlast Options. (line 33)\n* --no-header, rushwho: Rushwho Options. (line 26)\n* --security-check, rush: Option Summary. (line 11)\n* --show-default: Default Configuration.\n(line 21)\n* --show-default, rush: Option Summary. (line 31)\n* --test: Test Mode. (line 6)\n* --test, rush: Option Summary. (line 35)\n* --trace, rush: Option Summary. (line 46)\n* --usage, rush: Option Summary. (line 68)\n* --usage, rushlast: Rushlast Options. (line 45)\n* --usage, rushwho: Rushwho Options. (line 38)\n* --user: Test Mode. (line 29)\n* --user, rush: Option Summary. (line 54)\n* --version, rush: Option Summary. (line 60)\n* --version, rushlast: Rushlast Options. (line 37)\n* --version, rushwho: Rushwho Options. (line 30)\n* -b, file system test: File system tests. (line 9)\n* -c: Test Mode. (line 6)\n* -c, file system test: File system tests. (line 12)\n* -c, rush: Option Summary. (line 8)\n* -C, rush: Option Summary. (line 11)\n* -d: Test Mode. (line 32)\n* -D: dump mode. (line 10)\n* -D <1>: Option Summary. (line 22)\n* -d, file system test: File system tests. (line 15)\n* -d, rush: Option Summary. (line 18)\n* -e, file system test: File system tests. (line 18)\n* -f, file system test: File system tests. (line 21)\n* -F, rushlast: Rushlast Options. (line 9)\n* -f, rushlast: Rushlast Options. (line 18)\n* -F, rushwho: Rushwho Options. (line 9)\n* -f, rushwho: Rushwho Options. (line 21)\n* -g, file system test: File system tests. (line 24)\n* -G, file system test: File system tests. (line 27)\n* -h, file system test: File system tests. (line 30)\n* -h, rush: Option Summary. (line 64)\n* -H, rushlast: Rushlast Options. (line 33)\n* -h, rushlast: Rushlast Options. (line 41)\n* -H, rushwho: Rushwho Options. (line 26)\n* -h, rushwho: Rushwho Options. (line 34)\n* -i, rush: Option Summary. (line 28)\n* -k, file system test: File system tests. (line 34)\n* -L, file system test: File system tests. (line 30)\n* -L, file system test <1>: File system tests. (line 37)\n* -n, rushlast: Rushlast Options. (line 27)\n* -O, file system test: File system tests. (line 40)\n* -p, file system test: File system tests. (line 43)\n* -r, file system test: File system tests. (line 46)\n* -s, file system test: File system tests. (line 49)\n* -S, file system test: File system tests. (line 52)\n* -t, rush: Option Summary. (line 35)\n* -T, rush: Option Summary. (line 51)\n* -u: Test Mode. (line 29)\n* -u, file system test: File system tests. (line 55)\n* -u, rush: Option Summary. (line 54)\n* -v, rush: Option Summary. (line 60)\n* -v, rushlast: Rushlast Options. (line 37)\n* -v, rushwho: Rushwho Options. (line 30)\n* -w, file system test: File system tests. (line 58)\n* -x, file system test: File system tests. (line 61)\n* -x, rush: Option Summary. (line 46)\n* accounting: Accounting and Forked Mode.\n(line 6)\n* accounting database: Accounting Database. (line 6)\n* acct: Accounting and Forked Mode.\n(line 27)\n* acct, dump attribute: dump mode. (line 61)\n* acct-dir-mode: Accounting control. (line 14)\n* acct-dir-mode <1>: Accounting Database. (line 44)\n* acct-file-mode: Accounting control. (line 18)\n* acct-file-mode <1>: Accounting Database. (line 48)\n* acct-umask: Accounting control. (line 10)\n* acct-umask <1>: Accounting Database. (line 40)\n* actions: Operation. (line 18)\n* actions, system: System Actions. (line 6)\n* all, dump attribute: dump mode. (line 79)\n* all, include security flag: include-security. (line 16)\n* argv, dump attribute: dump mode. (line 23)\n* backreference interpretation: Lexical Structure. (line 66)\n* backslash interpretation: Lexical Structure. (line 42)\n* basic regular expressions: regexp. (line 6)\n* chdir: System Actions. (line 39)\n* checking file ownership: File system tests. (line 6)\n* checking file type: File system tests. (line 6)\n* chroot: System Actions. (line 17)\n* chrootdir, dump attribute: dump mode. (line 48)\n* clrenv: Environment. (line 9)\n* cmdline, dump attribute: dump mode. (line 20)\n* command: Request variables. (line 17)\n* command <1>: Formats. (line 126)\n* comparison: Comparisons. (line 6)\n* conditions: Operation. (line 18)\n* conditions <1>: Matching Conditions. (line 6)\n* config-error: Error Messages. (line 26)\n* configuration file syntax: Syntax. (line 6)\n* configuration file, testing: Test Mode. (line 6)\n* cvs: cvs. (line 6)\n* debug: Debugging. (line 9)\n* debugging: Debugging. (line 6)\n* debugging levels: Debugging. (line 17)\n* delete: delete. (line 8)\n* delete <1>: delete. (line 11)\n* diriwgrp, include security flag: include-security. (line 30)\n* diriwoth, include security flag: include-security. (line 34)\n* domain, localization: Localization. (line 28)\n* dump mode: dump mode. (line 6)\n* duration: Formats. (line 119)\n* environ, dump attribute: dump mode. (line 73)\n* Environment: Environment. (line 6)\n* error messages: Error Messages. (line 6)\n* evalenv: Environment. (line 45)\n* exit: Exit. (line 10)\n* exit <1>: Exit. (line 11)\n* exit rule: Exit. (line 6)\n* expand-undefined: Expansion control. (line 9)\n* expansion of undefined variables: Variable expansion. (line 54)\n* extended regular expressions: regexp. (line 6)\n* fall-through: Fall-through. (line 17)\n* fall-through rule: Operation. (line 38)\n* fall-through statement: Fall-through. (line 6)\n* fallthrough: Fall-through. (line 18)\n* fallthrough <1>: Fall-through. (line 6)\n* file ownership, checking: File system tests. (line 6)\n* file type, checking: File system tests. (line 6)\n* fork: Accounting and Forked Mode.\n(line 52)\n* fork, dump attribute: dump mode. (line 57)\n* forked mode: Accounting and Forked Mode.\n(line 12)\n* g, transform flag: set. (line 57)\n* gecos: Request variables. (line 15)\n* gid: Request variables. (line 13)\n* gid, dump attribute: dump mode. (line 54)\n* git: git. (line 6)\n* git-receive-pack: git. (line 6)\n* git-shell: git. (line 6)\n* git-upload-pack: git. (line 6)\n* global: Global. (line 6)\n* group: Membership operators.\n(line 16)\n* group <1>: Request variables. (line 11)\n* groupwritabledir, include security flag: include-security. (line 30)\n* groupwritablefile, include security flag: include-security. (line 22)\n* home: Request variables. (line 14)\n* homedir, dump attribute: dump mode. (line 51)\n* i, transform flag: set. (line 61)\n* i18n: Localization. (line 6)\n* identifiers, configuration: Lexical Structure. (line 22)\n* in, operator: Membership operators.\n(line 9)\n* include: Include. (line 9)\n* include <1>: Include. (line 6)\n* include-security: include-security. (line 11)\n* indexing, words in command line: Positional variables.\n(line 6)\n* insert: insert. (line 9)\n* insert <1>: insert. (line 10)\n* interactive: Interactive. (line 12)\n* interactive access: Interactive. (line 6)\n* interactive, dump attribute: dump mode. (line 30)\n* internationalization: Localization. (line 6)\n* iwgrp, include security flag: include-security. (line 22)\n* iwoth, include security flag: include-security. (line 26)\n* keepenv: Environment. (line 12)\n* l10n: Localization. (line 6)\n* legacy syntax: Configuration File. (line 37)\n* limiting number of simultaneous sessions: System Actions. (line 74)\n* limits: System Actions. (line 45)\n* link, include security flag: include-security. (line 38)\n* locale: Localization Directives.\n(line 9)\n* locale directory: Localization. (line 24)\n* locale name: Localization. (line 12)\n* locale, dump attribute: dump mode. (line 70)\n* locale-dir: Localization Directives.\n(line 14)\n* localedir, dump attribute: dump mode. (line 67)\n* localization: Localization. (line 6)\n* localization directives: Localization Directives.\n(line 6)\n* map: map. (line 6)\n* map <1>: map. (line 7)\n* match: Matching Conditions. (line 6)\n* matching conditions: Matching Conditions. (line 6)\n* message: Error Messages. (line 6)\n* msgfmt: Writing Your Localization.\n(line 41)\n* newgroup: System Actions. (line 13)\n* newgrp: System Actions. (line 12)\n* newline: Formats. (line 67)\n* nologin-error: Error Messages. (line 18)\n* options, command line: Option Summary. (line 6)\n* output formats: Formats. (line 6)\n* owner, include security flag: include-security. (line 19)\n* pid: Formats. (line 129)\n* post-socket: Notification. (line 10)\n* prog, dump attribute: dump mode. (line 26)\n* program: Request variables. (line 16)\n* pwdir, dump attribute: dump mode. (line 42)\n* pwgid, dump attribute: dump mode. (line 39)\n* pwname, dump attribute: dump mode. (line 33)\n* pwuid, dump attribute: dump mode. (line 36)\n* quoted strings: Lexical Structure. (line 36)\n* regexp: regexp. (line 9)\n* regular expressions: regexp. (line 6)\n* remopt: remopt. (line 9)\n* remopt <1>: remopt. (line 10)\n* request: Operation. (line 13)\n* request <1>: Request. (line 6)\n* rsync: rsync. (line 6)\n* rule: Operation. (line 18)\n* rule <1>: Rule. (line 13)\n* rule <2>: Rule. (line 6)\n* rule <3>: Formats. (line 122)\n* rule tag: Rule. (line 15)\n* rule, fall-through: Operation. (line 38)\n* rush, statement: Syntax. (line 16)\n* rush-po: Writing Your Localization.\n(line 21)\n* rush.rc: Configuration File. (line 6)\n* rushlast: Rushlast. (line 6)\n* RUSHLASTFORMAT: Rushlast. (line 33)\n* rushwho: Rushwho. (line 6)\n* rushwho, command line options: Rushwho Options. (line 6)\n* RUSHWHOFORMAT: Rushwho. (line 34)\n* s-expression: set. (line 42)\n* scp: scp. (line 6)\n* set: set. (line 9)\n* set <1>: set. (line 10)\n* set <2>: set. (line 18)\n* set <3>: set. (line 19)\n* set <4>: set. (line 25)\n* set <5>: set. (line 26)\n* setenv: Environment. (line 26)\n* sftp: sftp. (line 6)\n* simultaneous sessions: System Actions. (line 74)\n* sleep-time: sleep-time. (line 6)\n* start-time: Formats. (line 103)\n* stop-time: Formats. (line 113)\n* svn: svn. (line 6)\n* syntax version statement: Syntax. (line 16)\n* syntax, configuration files: Syntax. (line 6)\n* syntax, legacy: Configuration File. (line 37)\n* system actions: System Actions. (line 6)\n* system-error: Error Messages. (line 34)\n* tab: Formats. (line 71)\n* tag, rule: Rule. (line 15)\n* tcpmux: Notification. (line 17)\n* test mode: Test Mode. (line 6)\n* testing configuration file: Test Mode. (line 6)\n* text-domain: Localization Directives.\n(line 17)\n* textual domain: Localization. (line 28)\n* textdomain, dump attribute: dump mode. (line 64)\n* tilde expansion: System Actions. (line 18)\n* tilde expansion <1>: Include. (line 12)\n* time: Formats. (line 101)\n* time formats, for --time-format option: Time and Date Formats.\n(line 6)\n* trap rule: Exit. (line 36)\n* uid: Request variables. (line 12)\n* umask: System Actions. (line 8)\n* umask, dump attribute: dump mode. (line 45)\n* undefined variable, expansion: Variable expansion. (line 54)\n* unquoted strings: Lexical Structure. (line 30)\n* unset: unset. (line 6)\n* unset <1>: unset. (line 9)\n* unsetenv: Environment. (line 35)\n* usage-error: Error Messages. (line 12)\n* user: Request variables. (line 9)\n* user <1>: Formats. (line 98)\n* utmp: utmp. (line 6)\n* utmp file, accounting database: Accounting Database. (line 15)\n* vars, dump attribute: dump mode. (line 76)\n* word splitting: Positional variables.\n(line 6)\n* worldwritabledir, include security flag: include-security. (line 34)\n* worlwritablefile, include security flag: include-security. (line 26)\n* wtmp: wtmp. (line 6)\n* wtmp file, accounting database: Accounting Database. (line 15)\n* x, transform flag: set. (line 64)\n\n", "subsections": [] } }, "flags": [], "examples": [], "see_also": [] }