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. BMC Server Automation clients can run the following types of commands:
- Network Shell utilities, such as
midair, which each have distributed capabilities.
hostname $ mkdir //athens/tmp/foo //rome/tmp/bar
Besides launching external applications, the
nshutility provides access to many internal commands, including
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
nshcommand to run against a server, you also inherently authorize the use of all
nshinternal 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
For example, the
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.
|Allows users to execute Network Shell's internal commands, as well as to create and remove directories. |
No remote commands such as
Allows a user to execute the remote commands
This command does allow the user to do things like:
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
|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 $ nexec athens ps -ef rome $ cd //rome/etc athens $ ps -ef