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 Tree icon 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 Organization icon in your TREE domain. In the YourCo container, you create Finance as an Organizational Unit (OU) object Organizational Unit icon. 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 User icon 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

Example Tree Stucture in eDirectory

You can use the Directory Administration 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:

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

  2. As the user makes changes, the application records changes in the temporary file.

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

Rights Definitions

The actions for each right are described in Table 5-1.

Table 5-1 File System Trustee Rights

File-System Trustee Right

Description

Supervisor (S)

Grants the trustee all rights to the directory or file and any subordinate items.

The Supervisor right cannot be blocked with an IRF (Inherited Rights Filter) and cannot be revoked. Users who have this right can also grant other users any rights to the directory or file and can change its Inherited Rights Filter.

Default=Off

Read (R)

Grants the trustee the ability to open and read files, and open, read, and execute applications.

Default=On

Write (W)

Grants the trustee the ability to open and modify (write to) an existing file.

Default=Off

Create (C)

Grants the trustee the ability to create directories and files and salvage deleted files.

Default=Off

Erase (E)

Grants the trustee the ability to delete directories and files.

Default=Off

Modify (M)

Grants the trustee the ability to rename directories and files, and change file attributes. It does not allow the user to modify the contents of the file.

Default=Off

File Scan (F)

Grants the trustee the ability to view directory and file names in the file system structure, including the directory structure from that file to the root directory.

Default=On

Access Control (A)

Grants the trustee the ability to add and remove trustees for directories and files, to modify the rights assigned for trustees, and set the inherited rights filters.

This right does not allow the trustee to add or remove the Supervisor right for any user. Also, it does not allow to remove the trustee with the Supervisor right.

Default=Off

Supervisor Right

An eDirectory trustee of a Server object is automatically granted the Supervisor right [S] to the root directory of every NSS volume attached to that server. You cannot override the file system rights of the user with the Supervisor right by applying explicit rights or masking inherited rights at the subdirectory or file level.

The Admin User object is automatically a trustee of the Server object.

The Supervisor user of the NSS volume is automatically a trustee for all directories and files on the system and has all file-system trustee rights for them. The Supervisor right allows its trustee to assign other eDirectory objects as trustees and to specify any of the file-system trustee rights to them.

Also, a trustee with the Write right to the File Server object is granted the Supervisor right to the file system.

Access Control Right

A non-Supervisor trustee must have the Access Control right [A] to make trustee assignments in a directory or file. The Access Control right does not allow the user to add or remove the Supervisor right.

Default Trustee Rights

When you assign a trustee for a directory, the default rights are Read and File Scan [RF]. Any trustee assignment, whether for a directory or a file, also includes the right to see the path leading from the root to that directory or file. These are made visible by the visibility function; they are not actually set on the directories in the path.

Rights Needed for Typical Access Tasks

The following table lists some common tasks and the rights required to do them.

Task

Trustee Right Needed

Change directory or file attributes

Modify

Change the file or folder ownership

Access Control and be an administrator user of the server

Change the Inherited Rights Filter

Access Control

Change trustee assignments

Access Control

Copy files into a directory

Create

Create and write to a file

Create

Delete a file

Erase

Modify a directory’s disk space assignment for users

Access Control

Open or save a Microsoft Office file

Read, Write, File Scan, Create, Modify, Erase

Open or save an OpenOffice.org file

Read, Write, File Scan, Create, Modify, Erase

Read a closed file

Read

Remove an empty subdirectory

Erase

Rename a file

Modify

Search a directory

File Scan

See a file name (visibility)

File Scan

Write to a closed file

Write, Create, Erase, Modify

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 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, 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 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

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

  • Rights inherited for the user from the parent directory, with consideration of the inherited rights filter set for the subdirectory.

  • Rights set explicitly for the user on the directory.

  • Rights set explicitly for a security-equivalent object on the directory:

    • Explicit by assignment (Security Equal To property)

    • Automatic by membership in a group or role

    • Implied by its parent container and by the [Public] container

    More restrictive security-equivalent rights do not override rights granted for the trustee on the directory or for the trustee’s filtered inherited rights.

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

  • Rights inherited for the user from the parent directory, with consideration of the inherited rights filter set for the file.

    If the user has rights set on the parent directory or is security equivalent to an object with explicit rights set there, those are the rights that flow down to the file for the user and are subject to the IRF.

    Inherited rights for a file are ignored if rights are set explicitly for the object or for a security equivalent of the object. This behavior is different than for a directory.

  • Rights set explicitly for the user on the file.

    Inherited rights are ignored. Explicit trustee rights for a security equivalent object are added. More restrictive security-equivalent rights do not override rights set for the trustee on the file.

  • Rights set explicitly for a security-equivalent object on the file:

    • Explicit by assignment (Security Equal To property)

    • Automatic by membership in a group or role

    • Implied by its parent container and by the [Public] container

    Inherited rights are ignored. Explicit trustee rights are added.

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

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.

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.