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.

Platform

Location

Solaris, Linux, AIX, HP-UX

/etc/rsc/exports

Windows

<WINDIR>\rsc\exports (For example, <WINDIR> can be \windows or \winnt.)

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> <option1...optionN>

  • <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.

Option

Description

allowed=<username[:username]>

This option can be used to restrict access to specific users who do not have a local account. The user names entered here should be the login names of the users on the client machines. This option is similar to the validusers option except that the users named here are not required to have an account on the local system. The allowed= option is read before the validusers= option. If possible, use the validusers option instead of the allowed= option.

anon=uid

(UNIX only.) This option specifies how unknown users should be treated. If a request comes from an unknown user, the user is treated as an anonymous user and the effective user ID is uid. Root users (uid 0) are always considered "unknown" by the RSCD agent unless they are included in the root= option, described below. The default value for anon= is the UID of the user nobody. If the user nobody does not exist, the value 65534 is used. Setting anon=-1 disables anonymous access. The value entered can be numeric or a user name. If a user name is entered, the corresponding UID and GID are determined and set accordingly. If a UID is entered, a corresponding GID is searched for. If the GID is not found, the GID is set to the GID for the user nobody.

commands=<cmd1[:cmd2]>

By default, BMC Server Automation clients are allowed to execute any command against an agent. The commands= option allows you to limit the commands a client can execute against an agent. See Restricting commands for more details on how to use this option.

nomknod

(UNIX only.) By default, clients are allowed to create special files (character special and block special). Specifying the nomknod option instructs the RSCD agent to prevent the client from making a mknod(2) call generating an EACCES (Permission denied) error.

nosuid

(UNIX only.) By default, clients are allowed to create files with the setuid or setgid bits enabled and to set setuid and setgid permission using chown(2). If you specify the nosuid option, the RSCD agent silently ignores any attempt to enable the setuid or setgid bits when creating a file or changing a file's permissions.

ro

All clients have read-only access except those listed in the rw= option. The ro option takes precedence over the rw option if both are defined.

rw

All clients have read-write access except those listed in the ro= option. The ro option takes precedence over the rw option if both are defined.

rw=<hostname[:hostname]>

Hosts listed in this option are granted read/write permissions. Hosts not specified have read-only permissions if ro is defined or they are listed in the ro= option. If ro is not set or the host is not listed in the ro= option, the client is denied access. If both the ro= and rw= options are defined, the ro and rw options are ignored.

You can specify host names and/or IP addresses (in IPv4 or IPv6 formats). However when using an IPv6 address, ensure that the server address is enclosed in square brackets.

ro=<hostname[:hostname]>

Hosts listed in this option are granted read-only permissions. Hosts not specified have read/write permissions if rw is defined or they are listed in the rw= option. If rw is not set or the host is not listed in the rw= option, the client is denied access. If both the ro= and rw= options are defined, the ro and rw options are ignored.

You can specify host names and/or IP addresses (in IPv4 or IPv6 formats). However when using an IPv6 address, ensure that the server address is enclosed in square brackets.

root=<hostname[:hostname]>

This option gives root access to root users from specified hosts. The default is for no hosts to be granted root access.

You can specify host names and/or IP addresses (in IPv4 or IPv6 formats). However when using an IPv6 address, ensure that the server address is enclosed in square brackets.

rootdir=<dirname>

(Linux and UNIX only) By default, the rscd server allows the client to "see" the complete directory tree from / on down. By specifying the rootdir= option, the rscd server sets the "root" directory to <dirname> by making a call to or emulating chroot(2) . Clients can only see files and directories from <dirname> on down. When setting rootdir= on Windows systems, you can use the native file naming convention rather than a Network Shell path.

rsu=<user[:user]>

The client command rsu allows a client to get alternate remote permissions on the agent. By default the client is challenged for the user's password, but with the -p option no password is requested. The rsu= entry defines which users the client is allowed to rsu without challenging them for a password. If the client tries to use the rsu command with the -p option (that is, no password challenge) and then tries to switch to a user not in the list, access is denied.

user=<username>

This option forces all incoming client connections to run with the permissions of <username>. For Windows systems, you can enter Windows user account SIDs rather than user names. This option takes precedence over the root= and anon= options if they exist. The single entry you provide for <username> can be a user name or a numeric UID (UNIX only). On UNIX, if a user name is entered, the UID and GID for the user are determined and set accordingly. If the user name entered is not known, default user mapping applies.

If a numeric UID is entered, then the corresponding UID on the server is used even if no known user account is associated with that UID. If an account is associated with a UID, then its corresponding GID is also set. On Windows, if a user name or user account SID is entered, it is validated against a list of local users on the machine. If the user name that is entered is not known, access to the machine is denied. Note that on Windows domain controllers, you can map a user to a domain user. The user name you enter is validated against the domain users on the domain controller.

See How BMC Server Automation grants access to RSCD agents for more details.

validgroups=<groupname[:groupname]>

This option allows you to specify user groups that are allowed access. Enter user groups in a colon (:) separated list. For each group name and/or GID entered, the RSCD agent looks at the effective GID of the calling user (as reported by the calling host) and only allows it access if the GID is in the specified list. If the GID is not in the list, the connection is refused. Group information can be provided in the form of group names or numeric GIDs. The comparison is done as a numeric equivalency and as such group names must be known on the local system to determine their corresponding GID. Numeric GIDs do not have to correspond to a local group name. Use /etc/groups to define group names.

validusers=<username[:username]>

This option allows you to specify users who are allowed access. Enter users in a colon (:) separated list. For each user name and/or UID that is entered, the RSCD agent looks up the corresponding UID and user name to create a user name/UID combination. The RSCD agent then matches the user name/UID combination to each attempted client connection. If the user name and UID of the client connection does not exactly match one of the user name/UID combinations generated by the daemon, the connection is refused. The user information you provide for validusers= can be in the form of user names or numeric UIDs. User names and UIDs must correspond to a locally known user account. If no corresponding user account can be found, the entry is ignored.

Permission examples

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

ExampleDescription
* 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=-1Grants 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.
Notes:

  • On Windows, the user name entered is validated against a list of local users on the machine.
  • When using the exports file to set up user privilege mapping on Domain Controllers, map users to Administrator or an account in one of the BuiltIn groups.
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.

Was this page helpful? Yes No Submitting... Thank you

Comments