Configuring the exports file

This topic explains the purpose of the exports file, describes the available options, and details how to configure it. This topic includes the following sections:

About the exports file

The exports file determines which BMC Server Automation clients have access to a server. With the exports file you can set permissions on a per-client basis and, when necessary, use the users or users.local files to override those permissions for particular users. Often the exports file is used to set global permission that apply to users on all client machines.

For example, you can use the exports file to limit all clients to read-only permission on the server. Then you can use the users or users.local files to specify individual users who are granted read/write permission on that server.

Access permissions are defined for each individual RSCD agent and must be configured separately on each host where the RSCD agent is running. Updating the exports file on the host where you are running Network Shell or other BMC Server Automation applications does not set access permissions for managed servers.

When an rscd daemon starts on a server, it automatically reads the exports file. When changes are made to the exports file, the daemon automatically re-reads it. All subsequent client connections have the access permissions defined in the modified version of the exports file. Existing client connections are not affected by the changes. You do not have to restart the agent or otherwise instruct it to read the new exports file.

If the exports file does not exist or it does not contain any configuration information, you cannot establish a connection with an agent.

The exports file resides in different locations in Windows and UNIX systems, as described in the following table.

The exports file does not grant permissions on Windows servers to roles that are set up for Windows user mapping. For information about Windows user mapping, see the Windows user mapping and agent ACLs. If you are using Windows user mapping to grant permissions to roles, the exports file might still include entries that apply to Windows servers. Only the user mapping information in the exports file is ignored.

The following topics provide more information about configuring the exports file.

To configure the exports file

Create entries that correlate the host names of clients with the permissions that should be granted to those clients. Use the following format for each entry:

<hostNnames> is a list of comma-separated IP addresses, resolvable host names, or subnet designations. Subnet designations are used to define a range of addresses (see Subnet designations in configuration files). Using an asterisk 🟡️ instead of a list of host names defines default options that apply to any host not specifically named in the *exports* file.
<option1...optionN> is a list of comma-separated fields. Each option defines a type of access permission that applies to the hosts you have named in that entry. For a complete list of available options, see Options for exports file. If a single option sets multiple values, separate each value with a colon, as in the following:
validusers=user1:user2
Lines in the exports file that begin with # are considered to be comments.

Options for the exports file

For each of the entries in the exports file, you can apply any of the options listed below. When defining multiple options, enter options in a comma-separated list.

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 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, includingcd, 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 thecommands= option in the exports or users files. The order in which commands are entered and the format of thecommands= 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. No remote commands such as ps or df are allowed.
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. By leaving out the list of distributed commands, you limit the remote commands that can be executed. In this example, the user can execute all distributed commands, but is limited to the three remote commands specified after nexec.

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

Permission examples

The following code examples provide different levels of access to users and administrators.

Example	Description
* ro,rootdir=/pubs,user=guest	Allows customers access to software updates from servers. The asterisk means permissions apply to all clients unless there are other entries that define different permissions for specific hosts. Grants read-only access to all clients and maps all incoming connections so that users have "guest" privileges. The root directory for these users is set to /pubs.
* rw,nosuid,anon=-1	Grants read/write access to all users but turns off the setting of setuid/setgid bits and denies unknown users access.
admin1,admin2 rw,user=Administrator	Maps incoming connections from machines called admin1 and admin2 to the local user called Administrator. A configuration like this is typically necessary if you are deploying BLPackages to Windows machines because you need Administrator privileges to deploy packages. Notes: On Windows, the user name entered is validated against a list of local users on the machine. On Windows Domain Controllers, all users are domain users. When using the exports file to set up user privilege mapping on Domain Controllers, map users to Administrator or to the administrator account for the domain.
host1,host2,host3 rw,rootdir=/reports,root=host1 host4,host5 ro,rootdir=/reports	Allows both read/write and read-only access for selected hosts, granting them root access from only one host and changing the root directory to /reports.
host1,host2,host3 rw,rootdir=/reports,root=host1 host4,host5 ro,rootdir=/reports	Allows both read/write and read-only access for selected hosts, granting them root access from only one host and changing the root directory to /reports.
* rw,allowed=sysadmin1:sysadmin2,user=root	Grants two users (sysadmin1 and sysadmin2 ) read/write permission for all servers, and also maps their user privileges to root. Notes: This configuration can be assigned when administrators (who typically work on Windows clients) need to manage remote UNIX servers. Because Windows machines have no inherent concept of root, a configuration entry such as this example is important if administrators working on Windows clients want to modify the configuration of UNIX servers. This entry would be added to the exports file on every remote server being managed by the two administrators.
host1.foo.com rw,root=host1.foo.com @host1.foo.com/26 ro	Defines exception hosts and values for subnets. To create different access (ro/rw) permissions for various hosts within a subnet, you first define the exception hosts and then define the default value for the remaining subnet. In this example, the host (host1.foo.com) has read/write privileges while everybody else in the subnet (subnet mask 255.255.255.192) has read-only privileges.
@192.168.10.1/24 rw=@192.168.10.1/25,ro=@192.168.10.129/25	Splits an address range. In this example, an address range of 192.168.10.1-255 is split up such that the range from 1-127 has read/write privileges, while the range 128-255 has read-only privileges.