Restricting commands using the exports file and the users file
This topic describes how to restrict the commands a user can execute using the exports file and the users file. It contains the following sections:
How the agent determines access permissions
The RSCD agent reads entries in the exports file and users file to determine what access permissions a calling client should have.
Access can be limited by host or subnet, by user name, and by the commands a user can run. TrueSight Server Automation clients can run the following types of commands:
- Network Shell utilities, such as nsh, ls, and midair, which each have distributed capabilities.
For example: hostname $ mkdir //athens/tmp/foo //rome/tmp/bar
Besides launching external applications, the nsh utility provides access to many internal commands, including cd, pwd, true, false, set, echo, kill, and more. Given that these commands are internal to nsh, you cannot use the commands= option to explicitly restrict their use. After you use the commands= option to authorize the nsh command to run against a server, you also inherently authorize the use of all nsh internal commands against the server. - Remote commands (remote, that is, from the client's perspective). These commands do not have distributed capabilities and run remotely on the server host. (The process is conceptually similar to doing an rsh.)
For example, the ps, df, and netstat commands.
To prevent individuals from renaming executables to trick the RSCD agent, each distributed utility contains an encrypted string that is used to hard code the name of the utility into the executable. Remote commands do not include this safeguard.
Command restriction examples
In some circumstances you might want to restrict the commands a user can execute. This can be done using the commands= option in the exports or users files. The order in which commands are entered and the format of the commands= field affect the way permissions are determined.
A distinction exists between distributed commands and remote commands. You must first define the allowable distributed commands and then define the allowable remote commands. To allow remote commands, you must also allow the distributed command nexec. After the nexec entry is found, all the following commands in the list are assumed to be remote commands.
To summarize: First you define the distributed commands, the last of which should be the nexec command. Then you define the remote commands.
Example | Description |
|---|---|
commands=nsh:mkdir:rmdir | Allows users to execute Network Shell's internal commands, as well as to create and remove directories. |
commands=ls:nexec:ps:df | Allows a user to execute the remote commands ps and df, but does not allow a user to cd to the host: cd is not a remote command and the nsh command has not been authorized. This command does allow the user to do things like: rome $ ls //athens/foo/ |
commands=nexec:df:ps:netstat | Allows the user to execute all distributed commands while restricting the remote commands the user can execute on a host. In this example, the user can execute all distributed commands, but is limited to the three remote commands specified after nexec. |
commands=CM | Allows access from the Console but blocks NSH access, even through a job. This can be useful, for example, when loading a file or running a snapshot. |
The decision to allow or disallow execution of a remote command is based on comparison of the effective (basename) of the command. To ensure that only the desired remote commands are executed, you specify the full path name of the remote executable. This prevents users from trying to execute a different executable than the intended one.
For example, when you enter commands=nsh:nexec:/bin/ps, the following commands work as expected (executing from /bin/ps):
rome $ cd //rome/etc
athens $ ps -ef
Where to go from here