File-system trustee rights determine access and usage for directories and files on NSS volumes and Traditional volumes. A trustee is any eDirectory object, such as a User object, Group object, Organizational Role objects, or container object, that you grant one or more rights for a directory or file. Trustee assignments allow you to assign ownership, set permissions, and monitor user access.
The file system stores each file system Trustee’s ID and rights assignment as metadata with its directory or file in the NSS file system. In the NetWare Traditional file system, the file’s security and attributes metadata is stored in the Directory Entry Table (DET) of its parent directory. For NSS, the files and directory properties contain this information.
File-system trustee rights granted at the directory level apply to all the files and subdirectories in that directory, unless the rights redefined at the file or subdirectory level override them.
File-system trustee rights assigned to files and subdirectories redefine the rights that users inherit from directory rights. Eight file-system trustee rights can be granted at either the directory or file level, as described in the table below:
In NetWare, trustee rights assignments made at a given directory level flow down to lower levels until they are either changed or masked out. This is referred to as inheritance. The mechanism provided for preventing inheritance is called the Inherited Rights Mask (IRM).
IRMs are taken into account when NSS 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 NSS 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 NSS 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. The only way to keep an Admin-equivalent user from accessing files is to make a special trustee assignment that bars access to all but system connections. This assignment cannot be set through normal tools.
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 Admin and equivalents, which usually have rights resulting from an eDirectory rights inheritance). In this situation, the Admin user can see all files and folders 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.
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 NetWare or 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.
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.
A trustee of a Server object in eDirectory is automatically granted the Supervisor right [S] to the root directory of every NSS or NetWare Traditional volume attached to that server. You cannot override Supervisor rights with trustee rights applied at the subdirectory or file level, nor with Inherited Rights Filters. The Admin User object is automatically a trustee of the Server object.
The Supervisor user of the NSS or NetWare Traditional 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.
A trustee must have the Access Control right [A] to make trustee assignments in a directory or file.
Also, a trustee with the Write right to the File Server object is granted the Supervisor right to the file system.
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 other rights in any subdirectory on the volume. You can improve network security by granting each user privileges only to the specific directories he or she uses.
In a trustee assignment for a directory, the default rights are File Scan and Read. 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.
A new assignment of trustee rights at the file level can revoke rights assigned at the directory level, or it can allow additional rights.
Subdirectories and files can inherit rights from their parent directory. The directory’s rights flow down through its structure to subdirectories and files, except for specific subdirectories or files with their own trustee assignments that supersede inherited rights. The trustee can exercise rights on subordinate directories and files without having explicit trustee assignments on each item.
When granting a trustee assignment to a subdirectory or file, the trustee assignment takes precedence over the inherited rights of its parent directory.
[Public] is a specialized trustee; it is not an eDirectory object. [Public] represents any network user, logged in or not, for rights assignment purposes. [Public] 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.
The following table lists some common tasks and the rights required to do them.