6.3 Access Control Issues for NSS on OES Linux

This section describes how to use Novell eDirectory, NCP Server, and Linux User Management (LUM) with NSS to provide access to NSS volumes on OES Linux.

6.3.1 NSS and eDirectory

Users of the NSS volume and the Admin user (or Admin equivalent user) who manages the volume must be defined as users in Novell eDirectory. The locally defined Linux users, except for the root user, cannot see or access an NSS volume.

NSS controls access to data based on the Novell Trustee Model, which uses file system trustee assignments, trustee rights, and inherited rights filters to control file access. The trustee model depends on the secure directory services provided by eDirectory to manage the file system users. For example, eDirectory users must be authenticated by eDirectory to connect to the server, and then NSS uses the effective file system rights of the user to control access to specific files or directories. For information about the Novell Trustee Model, see Understanding File System Access Control for NSS and NetWare Traditional File Systems in the File Systems Management Guide for OES .

For information about managing users with eDirectory, see the Novell eDirectory 8.7.3 Administration Guide .

6.3.2 NSS, the Admin User, and the Root User

Admin and root are two very different concepts. It is important to understand the role of each in managing your NSS volume on OES Linux.

Admin User

The Admin user is an eDirectory user who is given all file system trustee rights. The Admin User account, or the Admin equivalent user account, must be defined in eDirectory, assigned as a trustee of the NSS volume, and given all file system trustee rights for that volume. In addition, to administer an OES Linux server, the Admin User account must be Linux-enabled with Linux User Management to have both an eDirectory GUID and a POSIX UID on the server. For more information about Linux-enabled eDirectory users, see Section 6.3.3, NSS and File System Users.

For a Linux server, the administrator logs in to iManager, NetStorage, or the Novell Client as the Admin user (or Admin equivalent user) to manage the NSS volume on Linux. NetStorage and the Novell Client are used to manage file system trustee assignments, trustee rights, inherited rights masks, and file and directory attributes. They can also be used to purge and salvage files.

Root User

Root is a local Linux user. The root user is the all-powerful connection when running on the Linux server. The root user is hardcoded internally in NSS to have all access rights to all files. In this way, the root user on Linux is similar to the Link Connection “0” user on NetWare. The root user is not defined as a user in eDirectory, and the root user is not Linux-enabled.

The root user logs in locally to use NSS utilities (such as NSSCON, NSSMU, RIGHTS, ATTRIB, METAMIG, RAVSUI, and RAVIEW) and NSS commands from the terminal console or the NSS Console (NSSCON). The root user can also execute applicable Linux commands and utilities.

NCP Server uses the root user internally for all Linux VFS (virtual file system) layer communication to the NSS volume, but it provides NSS with UIDs for file ownership via POSIX system calls, and it provides NSS with trustee information via XML calls.

6.3.3 NSS and File System Users

In addition to the root user and Admin user, file system users fall into three categories:

Local Linux Users

Users who are defined locally for the Linux server. The root user is the only local Linux user who can see and access the NSS volume.

eDirectory Users

Users who are defined in eDirectory and granted file system trustee rights to the NSS volume. When eDirectory and NCP Server are running, these users can access NSS volumes via the Novell Client or other NCP-based services such as NetStorage.

NSS uses the eDirectory GUID of a user to control access using the Novell Trustee model. Because they are not Linux-enabled, these users do not have a POSIX UID. Therefore, NSS cannot work with Linux to specify the user as the actual owner of a file. Whenever the user creates a file, NSS assigns the file ownership to the root user, using the root UID. NSS also cannot support user space quotas for these users.

If you move an NSS volume from a NetWare server to a Linux server, the file ownership information is unchanged in the existing files. However, because eDirectory users do not have a UID, NSS cannot report that information correctly to Linux. Instead, NSS identifies the owner as the Nobody user (if it exists) or the root user.

For information about managing users with eDirectory, see the Novell eDirectory 8.7.3 Administration Guide .

Linux-enabled eDirectory Users

Users who are defined in eDirectory, granted file system trustee rights to the NSS volume, and Linux-enabled with Linux User Management. These users can access an NSS volume with NCP, CIFS/Samba, NFS, AFP (requires a third-party solution), or Linux utilities, commands, or services.

Linux-enabled eDirectory users have both an POSIX UID and an eDirectory GUID, which enables NSS to assign and track ownership by user on Linux. NSS supports hardlinks and user space quotas for Linux-enabled eDirectory users.

IMPORTANT:Make sure to Linux-enable the users before setting hardlinks or user space quotas.

For information about installing and configuring Linux User Management and enabling users and groups for Linux, see the Novell Linux User Management Technology Guide for OES .

For more information about configuring trustees for NSS on Linux, see Access Control for NSS on Linux in the File Systems Management Guide for OES .

6.3.4 NSS and NCP Server

NCP Server works with Novell eDirectory, the Novell Client, and other NCP-based services such as NetStorage to authenticate and manage user sessions with OES Linux servers. When NCP Server is running, eDirectory users who have been granted file system trustee access can access an NSS volume with the Novell Client or NCP-based services.

NCP Server enforces access to files and directories based on the Novell Trustee model. NCP Server uses the root user identity for all communication via the Linux VFS (virtual file system) layer to the NSS volume, and then it provides NSS with UIDs for file ownership via POSIX system calls, and it provides NSS with trustee information via XML calls.

NSS does not rely on NCP Server to track file ownership and file system trustee assignments, trustee rights, and inherited rights. NSS must track this information, regardless of what NCP is doing, because it must be capable of delivering the files with other protocols, such as CIFS/Samba or NFS. Also, NSS must be able to work with applications running on the server. File ownership is not tracked by NCP; the information is stored by the file system. NSS tracks file ownership and enforces user space restrictions based on a user’s eDirectory GUID.

The Linux file system interface uses UTF-8 encoding for all file names. When accessing files with NCP, make sure to use the UTF-8 enabled NCPs that are available in the latest Novell NCP Client.

For information about configuring and managing NCP Server, see the Novell NCP Server for Linux Administration Guide .

6.3.5 NSS and Linux User Management

Novell Linux User Management is a directory-enabled application that simplifies and unifies the management of user profiles on Linux-based platforms. Only eDirectory users who are Linux-enabled with LUM can access files with non-NCP protocols such as CIFS/Samba, NFS, or AFP (requires a third-party solution) or Linux utilities, commands, or services. In addition, users must be Linux-enabled before you set up any NSS hard links for the volume and before you set user quotas.

IMPORTANT:If you Linux-enable a user who has been logged into the system before being Linux-enabled, make sure execute the resetidcache command from the NSS Console (nsscon) utility afterwards. This allows the proper reporting of ownership because it resets the mapping of user identities in the ID cache and forces it to update with the Linux UID for the user.

Linux-enabled eDirectory users have both UIDs as local Linux users and GUIDs as eDirectory users. The UID is needed to execute protocols and services that communicate to NSS through the VFS layer only. The user’s UID is also needed to map it to a GUID for tracking file ownership, managing hard links, and enforcing user space restrictions. In addition, NSS uses the GUID to enforce access to the files and directories based on the Novell Trustee Model, which uses file system trustee assignments, trustee rights, and inherited rights filters.

With non-NCP protocols and services, the UID is passed to NSS via the VFS layer. There is no back-end XML call to exchange GUID information as there is with the NCP interface. NSS uses a LUM API to translate the UID to a GUID, and then caches the result for fast mapping on subsequent access by the same UID. With the GUID-UID mapping, NSS can find the GUID for the user who issues the command, then executes the command. If the user is not Linux-enabled, NSS cannot identify a GUID for the UID it receives, and then rejects the command with an error. Only the root user is allowed to access NSS via the VFS layer without having an eDirectory GUID.

For information about installing and configuring Linux User Management and enabling users and groups for Linux, see the Novell Linux User Management Technology Guide .

6.3.6 Enforcing File Ownership and User Space Restrictions

Only Linux-enabled eDirectory users can have their user space restrictions enforced. You must Linux-enable the users first, then set the user space quota.

If a user is not Linux-enabled, any files created by that user are owned by the root user. When users are not Linux-enabled, NSS cannot record changes in ownership issued from the Linux interface. For example, if the root user issues a chown command and provides a UID of a user that is not Linux-enabled, even if that user is in eDirectory, the LUM API cannot find a matching UID, so NSS rejects the request.

6.3.7 Accessing Files as the Root User

When accessing an NSS volume from the Linux environment, the root user observes some information differently, depending on whether the eDirectory user is Linux-enabled, or not. Any native Linux commands run from a terminal console on the NSS volume, such as the ls command, are sent via the VFS layer. If the users are not Linux-enabled, instead of seeing the local UID of the eDirectory user who owns the file, the root user sees all files as belonging to either the Nobody user (if it exists) or the root user. NSS reports the Nobody UID or the root user UID for display purposes only; it does not change the true file ownership information stored as the user’s eDirectory GUID in the metadata of the file system.

For NSS volumes on Linux, the POSIX directory and file permissions are not used to determine access permission. NSS uses the permission fields to store Read Only, Read/Write, Execute, and Hidden attributes for directories and files. NSS does not allow the Linux system to set typical access control permissions in the POSIX fields. It interprets Linux chmod commands to apply the values as NetWare directory and file attributes, according to the way NSS maps them to the User, Group, and Other permission fields. For information and examples of how to interpret POSIX settings on your NSS volume on Linux, see Displaying Key NSS Directory and File Attributes as Linux POSIX Permissions in the File Systems Management Guide for OES.

6.3.8 Accessing Files via NCP Server Only

When the NCP Server is running and the NCP protocol is the only protocol or service used to access the NSS volume, the NCP Server controls access to the server for eDirectory users. If all of the following conditions exist, it is not necessary to Linux-enable the users with Linux User Management:

  • NCP Server must be running.

  • Only eDirectory users who have been granted file system trustee access to the volume and the root user have access to the NSS volume.

  • eDirectory users access files only through a Novell Client, NetStorage with NCP, or any other NCP-based service.

  • NCP Server enforces access to the volume based on the Novell Trustee Model for eDirectory users.

  • eDirectory users never need to execute Linux utilities, commands, or services on the volume.

  • eDirectory users never need to access the volume via other protocols such as CIFS/Samba, NFS, or AFP (requires a third-party solution).

For information about configuring and managing NCP Server, see the Novell NCP Server for Linux Administration Guide .

6.3.9 Accessing Files with Other Protocols or from Linux

Only the root user and Linux-enabled eDirectory users who have been granted trustee access can see and access the NSS volume from a Linux interface. eDirectory users must be Linux-enabled with LUM if they access files on the NSS volume with any protocol other than NCP, regardless of whether NCP Server is running. Except where NCP Server is controlling a process, NSS enforces the Novell Trustee Model for user access based on the UID, as mapped to the GIUD. NSS needs users to be Linux-enabled to correctly interpret the UIDs coming in from the VFS layer and match the owner’s UID with a GUID that ties back into eDirectory.

Users must also be Linux-enabled if the administrator wants users to be able to use any of the standard Linux utilities, commands, services, or APIs for the NSS volume. Users need a standard Linux UID to issue these commands, and NSS needs a GUID to execute it. Linux-enabled eDirectory users have both. NSS further controls access based on the effective file system trustee rights of the user. An example would be the chown command, which requires a username that is changed to a UID by the application, and then is sent via the VFS layer to the NSS volume. NSS matches the UID with a GUID, then is able to enforce the effective rights of the user and execute the command accordingly.

Because NSS controls access based on file system trustee rights, not by the POSIX permissions, Samba connections do not work until this trustee system has been configured for the Linux-enabled eDirectory users of the NSS file system. You cannot set up the standard POSIX permissions for Samba access to an NSS volume. Instead, the Admin user or Admin user equivalent must set up users in eDirectory and make file system trustee assignments, grant trustee rights, and configure inherited rights masks on directories. The eDirectory users must also be Linux-enabled.

For information about managing users with eDirectory, see the Novell eDirectory 8.7.3 Administration Guide .

For information about installing and configuring Linux User Management and enabling users and groups for Linux, see the Novell Linux User Management Technology Guide .

For information about configuring and managing Samba services for your OES Linux server, see the Samba Administration Guide .

6.3.10 Accessing Linux Traditional Volumes with NCP Server and Services

NCP Server also works with file systems other than NSS, such as Linux traditional volumes, which have no capability for storing trustees. If the eDirectory user is not Linux-enabled with LUM, when the user creates a file on a Linux traditional volume with the Novell Client (or NCP-based services), the NCP Server cannot identify the UID of the user, so it sets the owner UID to the UID of the root user. NCP Server cannot report back file owners as specific users on the Linux traditional volume if the user is in eDirectory but is not Linux-enabled for the server.

If the administrator wants NCP Server to record and report the true UID of a user who creates the file via the Novell Client, the user must be Linux-enabled. Otherwise, the UID that is saved is the UID of the root user.

For information about configuring and managing NCP Server, see the Novell NCP Server for Linux Administration Guide .