5.1 Understanding the OES Trustee Model for File System Access
The OES Trustee Model allows you to assign eDirectory objects as trustees on NSS volumes and NCP volumes and the directories and file on them, and then to assign file system rights to the trustees. The model’s inheritance function allows subdirectories and files to inherit rights from a parent directory in the directory tree, or to mask the rights that should not be inherited. The security equivalence function allows permissions to be assigned indirectly. The model also controls visibility of files and folders so that users can see only the directory paths needed to access the files where they have trustee rights.
The NSS file system natively supports the Trustee Model to control user access. The NCP Server on Linux emulates the Trustee Model’s functions for NCP volumes on traditional POSIX file systems (such as btrfs, Ext2/3, Reiser, and XFS). For NCP volumes, the actions are provided by the file access protocol and not the underlying native Linux file system. For NSS volumes, NCP Server synchronizes the emulated capabilities with the native capabilities of the NSS file system.
Before you assign trustees and set trustee rights, ensure that you have a solid understanding of the OES Trustee Model and how its various functions can be used to control user access to data on NSS volumes and NCP volumes.
5.1.1 Trustees
A trustee is any eDirectory object (such as a User, Group, Organizational Role, or container) that you grant rights to access a directory or file on an NSS volume or an NCP volume. Trustees and trustee rights can be assigned explicitly, or they can be assigned through inheritance and security equivalence. (These concepts are described in subsequent sections.)
IMPORTANT:NSS does not support dynamic and nested eDirectory groups. Although it is possible to add these groups as trustees in NSS volumes, NSS does not recognize the rights assigned to them as applying to group members.
Trustee assignments, and not file ownership, determine who can access a file. Administrator users can modify the ownership of files without affecting who has rights to access and use the files. Changing the file or folder ownership additionally requires that the user be the administrator user (or a user with the eDirectory Write right to the NCP Server object) for the server.
In OES, administrators, users, and network resources are represented as objects in an eDirectory database. The eDirectory structure is a flexible, hierarchical structure that can represent your business units, IT infrastructure, geographical locations, and so on.
Figure 5-1 illustrates eDirectory objects and their relationship to network resources and users. The TREE container 
is configured and created when you install eDirectory. Later, you must populate the tree with container and leaf objects to represent the various resources in your company. The YourCo container is the main Organization (O) object 
in your TREE domain. In the YourCo container, you create Finance as an Organizational Unit (OU) object 
. In the Finance container, you create Accounts as an OU object that contains all accounting resources. In the Accounts container, Bob is a User object 
for a system user who is assigned to the Accounts Department. Other OUs in the Finance container might represent Purchasing and Billing organizations. Other OUs in the YourCo container represent organizations at the same level as Finance, such as Sales, Marketing, and Manufacturing.
Figure 5-1 Example eDirectory Container and Objects
You can use the option in iManager to create eDirectory objects. For information, see Managing Objects
in the NetIQ eDirectory 8.8 SP8 Administration Guide.
Trustees can be set at multiple levels to get different results. The following sections describe how trustees work at different levels in the file system.
Admin User and Admin-Equivalent Users
File system access for the Admin user and Admin-Equivalent users is not granted in the file system. Instead, a bit is set in the connection table to indicate that the user is an administrator and as such has full access to the server and all volumes thereon. The Admin user automatically has the Supervisor right to the Server object and can see all files and directories.
When you set a non-admin User object as security equal to the Admin user, you grant the user all the privileges of the Admin user. These privileges cannot be restricted by rights for that User object through explicit trustee assignment, security equivalence to other groups or other users, or inheritance. For information, see Section 5.2, Configuring a Non-Admin User to be an Admin-Equivalent User.
Granting a user Admin-equivalence might be desired if the Admin-equivalent user has broad responsibilities for eDirectory and file system management. However, it provides more privileges than are needed if the administrator role you want to define has limited management responsibilities.
To increase security or to support a distributed administration model, you can create a special object for the administrator role and restrict file system and eDirectory rights required based on their administration responsibilities. For an example of how to set up a special GroupWise administrator identity and assign the appropriate eDirectory rights and file system rights, see Assigning Rights Based on Administration Responsibilities
in the GroupWise 2012 Administration Guide.
[Public] Trustee
[Public] is a special trustee; it is not an eDirectory object. The [Public] trustee represents any network user, logged in or not, for rights assignment purposes. The [Public] trustee has Browse rights to the top of the tree, giving all users the right to view any object in the tree.
You can always specify [Public] as the trustee of a file, directory, or object. An unspecified authorized user who tries to access a file, directory, or object without any other rights is allowed the rights granted to the [Public] trustee.
IMPORTANT:For security reasons, you should not provide the file system Supervisor right to the [Public] trustee.
For information, see Section 5.3, Configuring [Public] as a File System Trustee.
For an example of how to use the [Public] trustee, see Section 5.4, Configuring the [Public] Trustee Access Rights on NSS Volumes for Daemons Running as the Nobody User.
Volume-Level Trustees
If you grant a user privileges at the root directory of a volume, the user gains privileges to the entire volume unless those rights are specifically revoked at a lower level. You should be especially cautious about granting the Access Control right in a root directory. Users with the Access Control right can grant themselves all rights (except Supervisor) in any subdirectory on the volume. You can improve network security by granting users privileges only to the specific directories they use by setting trustees explicitly or by leveraging the inheritance and security equivalence functions.
Subdirectory-Level Trustees
An assignment of trustee rights for a user at the subdirectory level can revoke rights assigned at a parent directory, or it can allow additional rights. Trustee rights granted on directories determine which rights are allowed to flow down for that trustee to the child subdirectories and files. The effective rights for a user on the current subdirectory are the combined set of explicit rights for the user plus security equivalence rights plus the filtered inherited rights.
File-Level Trustees
An assignment of trustee rights for a user at the file level can revoke rights assigned at the parent directory, or it can allow additional rights. For this user, inherited rights are ignored. The user’s rights are the combined set of explicit rights for the user plus security equivalence rights. More restrictive security-equivalent rights do not revoke the explicitly set user rights.
IMPORTANT:File-level rights work for read-only files or for file types where applications do not delete the original file when saving changes.
File-level trustee rights can be problematic because of how third-party applications handle file modifications. When a file is opened for writing, many applications function as follows:
-
The application copies the file to a temporary file in order to save internal memory or as a safety net to prevent data loss due to a power failure, system crash, or human error.
-
As the user makes changes, the application records changes in the temporary file.
-
When the user saves changes, the application deletes the original file, and then creates a new file (or renames the temporary file) with the same name as the original.
When the application deletes the original file, the trustee settings on the file are automatically deleted. The file system sees the replacement file as a new file. The file system is not application aware; that is, it does not track the ultimate intent of the applications that you might use.
5.1.3 Inherited Trustee Rights
Subdirectories and files inherit rights from their parent directory. Typically, you set rights that you want to flow down to all users by assigning a Group object as the trustee of a directory located at the root of the volume. The trustee rights flow down through the file tree structure to its child subdirectories and files.
Setting rights for a trustee on a directory or a file changes inheritance in the following ways:
-
Directory: Trustee rights granted on directories determine which rights are allowed to flow down for that trustee to the child subdirectories and files. The inherited rights filters set on child subdirectories and files are applied to the trustee’s rights set on the parent directory.
-
File: Trustee rights granted on a file determine which rights are allowed for the user. For this trustee or its security-equivalent trustees, inherited rights are ignored.
You can mask or filter what rights can be inherited. The Inherited Rights Mask (IRM) is the set of rights that you block from inheritance, while the Inherited Rights Filter (IRF) is the set of rights that you allow to be inherited. The IRM and IRF apply only to rights coming down the tree from parent directories. They do not affect any rights granted at the point where you set the IRM or IRF. The IRF settings for the file or directory apply for all trustees except users with the Supervisor right, the Admin user, or the Admin-equivalent users for the server.
For example, in iManager, the Files and Folders plug-in allows you to view or modify the Inherited Rights Filter for a selected file or folder by viewing its , then clicking the tab. By default, all rights (SRWCEMFA) are allowed to be inherited, as shown in Figure 5-2. You deselect a right to disable it from being inherited by the file or folder. That is, the right is masked so that it cannot flow down.
Figure 5-2 Viewing or Modifying the Inherited Rights for a File or Folder
IRMs are taken into account when NSS or NCP Server builds what is referred to as the effective Access Control List (ACL) for a file or directory. The effective ACL is a list of all users who have rights to the directory and includes the rights they have. It is calculated by starting at the root of the volume and working down to the file.
At each level, the IRM is applied to all rights inherited from the parent directory. Only those rights allowed by the mask are inherited by the child object. Rights for the various trustees explicitly assigned to the child are then collected. When a trustee inherits rights from above, the new rights replace the old ones (except the Supervisor right, which cannot be masked or removed by a new assignment to the same trustee).
By the time that NSS or NCP Server reaches the target file or directory, it has a list of all trustees and the rights assigned and inherited for the requested file or directory. This list is then compared against the entries in the connection table structure. Every time there is a match in the connection table with an entry in the effective ACL, the rights are added to those that the owner of the connection has to the requested file or directory.
In reality, the rights are not calculated at every directory level. The actual algorithm that NSS or NCP Server uses to calculate the rights for a particular file or directory is somewhat complicated because it ties in closely with the way the rights cache is implemented. The algorithm almost never needs to start at the root and work down.
In effect, when the effective rights of a user to an object are finally resolved, you have a list of all users who have rights to the file or directory (the effective ACL) and a list of all users in the connection table. These lists are seldom very large.
The one exception to this is a connection that has Admin-equivalent rights (not to be confused with having the Supervisor right from a trustee assignment). Admin-equivalent users have all rights to files, and they cannot be masked out by an IRM, IRF, or explicit trustee assignment.
All rights other than Supervisor can be stripped away with an IRM or IRF at any level for nearly any user, except a user that has Supervisor right to the Server object itself (such as the Admin user and the Admin-equivalent users, which usually have rights resulting from an eDirectory rights inheritance). In this situation, the Admin user can see all files and directories regardless of IRMs or IRFs because the access is not granted in the file system. Instead, a bit is set in the connection table to indicate that the user is an admin and as such has full access to the server and all volumes thereon.
5.1.4 Security Equivalence
Security equivalence means having the same rights as another object. When you make one object security equivalent to another object, the rights of the second object are added to the rights of the first object when the system calculates the first object's effective rights.
Security equivalence helps to simplify the task of assigning objects as file system trustees for your directories and files. Security equivalence is recorded in eDirectory as the value for the property of an eDirectory object. Security equivalence granted rights are added to any rights explicitly granted for an object. For a directory, they are also added to the filtered inherited rights.
Security equivalence is effective only for one step; it is not transferred by a subsequent security equivalence. For example, if you make a third user security equivalent to Joe in the example above, that user receives only Joe’s original security settings. The third user does not receive Admin rights or any other Security Equal To properties Joe might have.
Whenever a user attempts to access a network resource, eDirectory calculates the user’s security equivalence and makes that information available to the NCP Server. NCP Server compares the user’s security equivalence information to the trustee assignments for the path and target directory or file to determine if the user can access the target resource and what action on it is permitted.
You can establish security equivalence by using the following methods:
Explicit Security Equivalence
An eDirectory Administrator can modify an object’s property to explicitly assign it the same rights as those assigned to another object.
For example, in iManager, you can use the > option to make a User object named sam to be the security equivalent to the User object named bob, as shown in Figure 5-3. After you create the security equivalence, sam effectively has the same rights to the file system tree as those explicitly assigned to bob.
Figure 5-3 The Security Equal To Property for eDirectory Objects
Automatic Security Equivalence
Security equivalence is also achieved by membership in a group or role. Whenever you assign an object to be a member in a Group object or Organizational Role object, the security equivalence is automatically added to the member object’s property.
For example, in iManager, you can use the > option to add the User object named sam as a member of the Group object named team, as shown in Figure 5-4. The team object is automatically added to the property for sam, as shown in Figure 5-4. All members of the Group object, including sam, effectively have the same rights to the file system tree as those explicitly assigned to team.
Figure 5-4 The Membership Property for eDirectory Group Objects
Figure 5-5 Group Memberships Added Automatically to the User’s Security Equal To Property
An Organizational Role object defines a position or role within the organization that can be filled by any designated user. The organizational role is particularly useful for delegating administrative authority, such as for rotating positions that support multiple employees, where the responsibilities of the job, and the network access required, are static. Another use is for the segregation of duties, where company or regulatory policies require that specific tasks be performed by different users. For example, you might not want the same person both to acknowledge the receipt of goods and to process payment to the vendor. If a User object is assigned as an occupant of an organizational role, the user is automatically granted all file system trustee rights assigned to the role. Some organizational role examples include postmaster, network administrator, help-desk workers, physicians, and academic faculty.
Implied Security Equivalence
Equivalent to all parent containers and the [Public] trustee. Security equivalence for an object is implied by its parent container and by the [Public] container, which applies to all users. For information about setting rights for the [Public] trustee, see [Public] Trustee.
5.1.6 Visibility
The OES Trustee Model also controls visibility into the file system. For example, the user Joe is made a trustee of the Joe folder, and has access only to files in the Joe folder. Figure 5-6 demonstrates how Joe’s view of the file system differs if the files are on a volume where the Trustee Model is applied as compared to the ACL (Access Control Lists) method on other file systems.
Figure 5-6 File System Tree View for Joe with the Trustee versus ACL Methods
A user who is a trustee with the Access Control (A) right or Supervisor (S) right can assign other users as trustees of files in directories and set rights for them. A user who has only the Access Control right cannot modify the Supervisor right of another user. For example, the user Amy is the trustee of her home directory and has the Access Control right. Amy makes Joe a trustee of the read-only o.mpg file in her personal Amy folder, and grants Joe the Read Only access to the file. On an NSS file system, Joe now sees the \Amy\o.mpg path and file in addition to his personal Joe folder. Joe cannot see other files in the Amy folder.
Figure 5-7 File System Tree View of a Shared File for Joe with the Trustee versus ACL Methods
5.1.7 Visibility Lists
The Visibility list is only used for making parent directories visible for navigation purposes. If a user has rights to a file, the NCP (via NCP Server for Linux) makes all directories above the file visible to the user. This saves the administrator the task of assigning explicit rights to each directory above where the actual rights are assigned, as illustrated in Figure 5-8.
Figure 5-8 Visibility for Trustee versus ACL Methods
Visibility entries are stored in a manner similar to explicitly-assigned trustees. The first four entries are in the actual beast object; the rest are stored in overflow beast objects linked from the directory beast object.
Visibility lists only appear on directories. There is one entry for every trustee assigned anywhere in the subtree below the directory. Therefore, the further toward the root you go, the more GUIDs you see against that directory. At the root, the list has GUIDs for every trustee on the volume.
Each visibility entry has an eDirectory GUID and a count of the number of references to that GUID in the entries for the directory (not the subtree) where the Visibility list is assigned. This includes trustees that are explicitly assigned, as well as trustees in Visibility lists.
A Visibility list entry can be created in one of two ways:
-
An immediate subordinate directory or file has a trustee that the parent does not.
-
A visibility entry for a subordinate subdirectory is present.
Visibility counts do not consider trustees from directories or contents of directories that are not immediately subordinate to the considered directory.
The Visibility list is not affected by adding, deleting, or modifying IRMs. These operate in a transverse flow to the Visibility list. In other words, IRMs flow down the directory structure, while the Visibility list works up the structure.
For each request, GUID entries in the connection table are compared for the connection requesting against all GUIDs on the directory in question. If a match is found, the directory is made visible to the user in the Visibility list.