Administrative lists determine which users are permitted to perform privileged operations, such as restoring user files from backup copies or moving filesets from one server machine to another. Because they are stored on the local disk of each machine, administrative lists provide local control over a machine.
Each type of server process is associated with an administrative list, which allows you to differentiate between users who perform different administrative tasks. For example, administrative users who start and stop server processes need to be included on different administrative lists from users who manipulate filesets. (See Using Administrative Lists and Keytab Files for details about the administrative tasks associated with each administrative list.)
Rather than specifying individuals in administrative lists, you can use groups in much the same way that you can use groups in ACLs. (You may want to use the same groups for ACLs and administrative lists in certain instances.) For example, you can create a large group of users for performing backup operations and include them on the administrative lists required to use the DFS Backup System (admin.bak, admin.fl, and admin.ft). A subset of this group can be included in the administrative list (admin.bos) for the BOS Server process on each machine in a domain, since that list designates the users and groups permitted to control server processes.
In two important cases, administrative users are specified as a group in command options. These groups are defined in the Registry Database, as are groups specified with ACLs and administrative lists; however, only one group can be specified with each of these commands.
The first command, fxd, initializes the File Exporter and starts related kernel daemons. The group specified with the command's -admingroup option can change the ACLs and UNIX permissions associated with all file system objects exported from the File Server machine on which the File Exporter is running. They have the equivalent of the ACL c permission on all of the files and directories in each exported DCE LFS fileset, and they can effectively change the UNIX permissions on all of the files and directories in each exported non-LFS fileset. They can also change the owner and owning group of any file system object exported from the machine, and they can change the default cell of any DCE LFS object exported from the machine. Because they have access to all of the exported DCE LFS and non-LFS filesets on the File Server machine, members of this group should be both few in number and highly trusted.
While inclusion in this administrative group is similar in many respects to being logged in as root, the two are not equivalent. A user who is logged into the local machine as root can perform different operations on a file or directory, depending on whether the user accesses the object via its DCE pathname or via its local pathname.
The first way a user can access a file or directory is via the object's DCE path name. For DCE access, DFS treats a user who is logged into the local machine as root but is not authenticated to DCE as the /.../cellname/hosts/hostname/self principal of the local machine; in this case, the root user receives the permissions associated with the machine's self principal, which is treated as an authenticated user from the local cell. If the user is also authenticated to DCE as root, DFS treats the user according to the DCE identity root. The DCE identity root effectively has root privileges for data in all exported non-LFS filesets in the cell, which is a serious security risk. Use the DCE root identity very cautiously or disable it altogether.
The second way a user can access a file or directory is via the object's local path name. For local access, the root user has all of the privileges commonly associated with root; the root user can perform any file system operation on a file or directory. Note that a file or directory in a non-LFS fileset can always be accessed via a local path name because a non-LFS fileset must always be mounted locally, as a file system on its File Server machine; a file or directory in a DCE LFS fileset can be accessed via a local path name only if its fileset is mounted locally.
In summary, being a member of the fxd administrative group allows you to perform any operation on a file or directory in an exported fileset, but you may have to change the file's or directory's protections first. Being logged into the local machine as root lets you perform any operation on a file or directory in a locally mounted fileset immediately, without first changing the protections. Being authenticated as DCE root lets you perform any operation on a file or directory in an exported non-LFS fileset immediately.
The second command, fts crserverentry, creates a server entry in the FLDB for a specified File Server machine. The group specified with the command's -owner option can administer entries in the FLDB for all filesets on the File Server machine. If the same group is given ownership of the server entries for all of the File Server machines in a domain, members of that group can then manipulate the FLDB entries for all of the filesets in the domain. Specifying a group with fts crserverentry is an alternative to specifying the same group in the admin.fl list, which would allow members of the group to access FLDB entries for filesets on all machines in the cell.
The number and size of a cell's administrative groups depend upon the organization of the cell. For example, a cell with a simple organization - one with a single administrative domain - could have the following two basic administrative groups:
· A group for cell-wide file system and fileset administrators (cell_fileset)
· A group for all server principals in the cell (cell_servers)
It could also include a third administrative group (cell_file_system). The members of this group would be a highly trusted subset of the members of the cell_fileset group. The table below lists the groups associated with each administrative list when only two groups are used and the groups associated with each administrative list when three groups are used. It also describes the function of the groups included in each list.
Suggested Groups for Administering a Single-Domain Cell
| Administrative List |
With Two Groups | With Three Groups | Function |
| admin.bos | cell_fileset | cell_file_system | Manage server processes on each server machine |
| admin.fl | cell_fileset | cell_fileset | Create server and fileset entries in the Fileset Location Database on each Fileset Database machine |
| admin.ft | cell_fileset cell_servers |
cell_fileset cell_servers |
Manage filesets on each File Server machine; move filesets between File Server machines |
| admin.bak | cell_fileset | cell_fileset | Modify the Backup Database on each Backup Database machine |
| admin.up | cell_servers | cell_servers | Allow upclient processes to obtain files from upserver processes on server machines |
If the third group, cell_file_system, is used, it replaces the cell_fileset group on the admin.bos lists on all server machines in the cell to allow its members to control the server processes on the machines. It also replaces the cell_fileset group on the -admingroup option of each fxd command for the File Server machines in the cell to enable its members to modify the permissions of all exported filesets in the cell.
An additional usage of the -owner option of the fts crserverentry command and the -admingroup option of the fxd command is to allow owners of local workstations to export data from their local disks to the global namespace. In this case, a group consisting of the owners of a local workstation is specified with these options when a server entry is created for the workstation and when the File Exporter is initialized on the machine. (See Making Filesets and Aggregates Available for more information about creating server entries.)