5.1.1 Trustees

A trustee is any Novell 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.)

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 Directory Administration option in Novell iManager to create eDirectory objects. For information, see Managing Objects in the Novell eDirectory 8.8 SP7 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.

5.1.2 File System Trustee Rights

Trustee rights are file system rights and not eDirectory rights. They govern the actions that a trustee can perform on a directory or file that resides on an NSS volume or NCP volume. Trustee rights can be granted explicitly. However, you can also leverage inheritance and security equivalence to provide effective rights to a user. (These concepts are described in subsequent sections.)

NCP Server stores the trustee IDs and rights settings on each volume in the ._NETWARE/.trustee_database.xml file. For NSS volumes, the file system also stores each trustee’s ID and rights assignment as metadata with the directory or file where the assignment is made.

Supervisor (S)

Read (R)

Write (W)

Create (C)

Erase (E)

Modify (M)

File Scan (F)

Access Control (A)

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:

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 or 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 Properties, then clicking the Rights 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 or explicit trustee assignment.

All rights other than Supervisor can be stripped away with an IRM 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 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 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 Security Equal To 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 Security Equal To property to explicitly assign it the same rights as those assigned to another object.

For example, in iManager, you can use the Directory Administration > Modify Object 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 Security Equal To property.

For example, in iManager, you can use the Directory Administration > Modify Object 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 Security Equal To 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

5.1.5 Effective Rights

A user’s explicit rights on a directory are combined with the filtered rights inherited from its parent directory. Any rights through security equivalence are also applied.

A user’s explicit rights on a file override any rights that can be inherited from its parent directory. In this case, the user has only the rights granted, and the inherited rights are ignored. If the user is a member of another group or role that also has explicit rights to the file, the user’s effective rights on the file are a combination of the rights granted for the user and the rights granted for the group or role. If the rights of the group or role are more restrictive than the user’s explicit rights, it has no effect on rights granted to the user.

An object’s effective rights to a subdirectory are the set of distinct rights from the following:

An object’s effective rights to a file are determined by the following:

For more information, see How Effective Rights Are Calculated in the Novell eDirectory 8.8 SP7 Administration Guide.

5.1.6 Visibility

The Novell 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 settings for a trustee with Supervisor rights. 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 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:

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.

5.1.8 Security Equivalence Vector

NCP Server and NSS work together to ensure that the Security Equivalence Vector is up-to-date, and that the entries in it are used to give correct access to the file system.

The Novell Client establishes an authenticated connection to the server through eDirectory. It does not perform periodic authentication checks, nor does it track rights. The client does not control the rights process. To do so would introduce a security flaw into the client/server relationship.