Restricting commands

The RSCD agent reads entries in the exports 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 two types of commands.

• The first are 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.
  
• The other type of command that a client can run is called a remote command (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, remote commands include ps, df, and netstat.
  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.
  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 subsequent commands in the list are assumed to be remote commands. In other words, first you define the distributed commands, the last of which should be the nexec command. Then you define the remote commands. For example,
  commands=nsh:mkdir:rmdir
  allows users to execute Network Shell's internal commands as well as to create and remove directories. No remote commands such as ps or df are allowed. The entry
  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 because 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/
  If you only want to limit the remote commands that can be executed, you can leave out the list of distributed commands. For example,
  commands=nexec:df:ps:netstat
  allows the user to execute all distributed commands but only allows the user to execute three remote commands on this host.
  The decision to allow or disallow execution of a remote command is based on comparison of the effective (basename) of the command. In order to ensure that only the desired remote commands are executed, you can 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, if 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