This section describes how Novell eDirectory, NCP (NetWare Core Protocol) Server, and Linux User Management (LUM) work with Novell Storage Services to provide access to NSS volumes on OES 2 Linux servers.
The Administrator user and the Linux root user are two very different concepts. It is important to understand the role of each in managing your NSS volume on OES 2 Linux servers.
The Administrator user is an eDirectory user who is given all file system trustee rights for the server, including the Supervisor right. The Administrator user account, or the Administrator equivalent user account, is given the following privileges:
The user identity and credentials are defined in eDirectory.
The user is assigned as a trustee of the NSS volume and given all file system trustee rights for that volume. You can also create a group for administrators with equivalent rights, and assign the user to that group.
The username must be Linux-enabled with Linux User Management (LUM), which gives the user both an eDirectory GUID and a POSIX UID on the server.
NOTE:You might see the user with the same eDirectory GUID even after LUM disabling the user. This is because NCP server clears its cache periodically at the interval of 30 minutes.
During this time do not restart edirectory. Run nsscon /ResetIDCache after 30 minutes. For more information on ID Cache Commands, see Section A.5.3, ID Cache Commands.
The user belongs to the Administrator group for the server that is Linux-enabled with LUM.
The Administrator user who installs NSS on OES 2 Linux is automatically given these privileges. Any other administrator, including the Tree Administrator user, who you want to be able to manage the NSS storage must be manually configured with the same privileges.
IMPORTANT:The Tree Administrator user is not automatically granted permissions to OES Linux servers installed in the tree.
For more information about Linux-enabled eDirectory users, see Section 5.5.2, NSS File System Users.
For a Linux server, the administrator logs in to iManager as the Administrator user (or Administrator equivalent user) to manage the NSS volume on Linux. The Administrator user can also use the iManager Files and Folders plug-in, NetStorage, and the Novell Client to manage file system trustee assignments, trustee rights, inherited rights masks, and file and directory attributes. These tools can also be used to purge and salvage files for volumes where the Salvage attribute is enabled.
The root user is a local Linux user who 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 with LUM. This allows you to log in to the server as the root user when eDirectory services are not available. The root user is the only local Linux user who is allowed to access NSS via the VFS layer without having an eDirectory GUID.
The root user logs in directly to the server to use NSS utilities (such as nsscon, nssmu, rights, attrib, metamig, ravsui, and raview) from the terminal console and to issue NSS command line commands from the NSS Console (NSSCON). The root user can also execute applicable Linux commands and utilities.
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 that 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.
IMPORTANT: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.
In addition to the root user and Administrator user, file system users fall into three categories:
NSS uses the eDirectory GUID of a user to control access by using the Novell Trustee model. Users of the NSS volume and the Administrator user (or Administrator equivalent user) who manages the volume must be defined as users in Novell eDirectory. For information about managing users with eDirectory, see the Novell eDirectory 8.8 Administration Guide.
To grant access to eDirectory users, you must assign them to be trustees in the file system, grant them file system trustee rights, and set inherited rights filters. For more information about configuring trustees for NSS on Linux, see Section 20.1, Configuring File System Trustees, Trustee Rights, Inherited Rights Filters, and Attributes.
Linux-enabled eDirectory users are users who are defined in eDirectory, granted file system trustee rights to the NSS volume, and Linux-enabled with Linux User Management. Linux-enabled eDirectory users have both a POSIX UID and an eDirectory GUID. You must Linux-enable users who need to access NSS volumes via Samba, NFS, third-party AFP solutions, or who need to use Linux utilities, commands, or services. NetStorage for Linux requires that users be Linux-enabled if NetStorage is configured to use OpenSSH for user access.
WARNING:When creating a LUM (Linux-Enabled eDirectory User) user consider the following:
Do not assign the same UID as any local Linux users and the vice versa.
Ensure that LUM user names do not conflict with any of the local Linux users name.
Assigning conflicting or duplicate UID's or LUM user names result in NSS access violations.
IMPORTANT:A Linux service or utility must also be enabled for LUM in order for users to access the file system with it.
For OES 2 Linux and later, it is no longer necessary to Linux-enable the users with LUM in order for user quotas (space restrictions) to be enforced. NCP Server for Linux has been modified to provide the GUID information that NSS needs for file ownership. NSS uses file ownership information to enforce user space restrictions based on a user’s eDirectory username.
Users who create hard links must be Linux-enabled in order to use the ln command on the server. It is not necessary to Linux-enable users if they are only consumers of the hard link.
Beginning in OES 2 SP2 Linux, if users are Linux-enabled with LUM or not, the file creator, modifier, and deleter fields are recorded with the username of the user who performs the action. In prior releases of OES 2, the deleter field is recorded as the root user or Nobody user (if it exists) if the user is not LUM enabled.
NOTE:In OES 1 Linux, the modifier field and deleter field are reported as the root user or Nobody user for non-LUM-enabled users.
For information about installing and configuring Linux User Management and enabling users and groups for Linux, see the OES 2 SP3: Novell Linux User Management Administration Guide.
Local Linux users are 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.
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 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 Using Trustees
in the OES 2 SP3: File Systems Management Guide.
For NSS volumes on Linux, the POSIX directory and file permissions are not used to determine access permission. Access control is based on the Novell trustee model and not on the POSIX permissions or access control lists (ACLs). NSS uses the POSIX permission fields to display Read Only, Read/Write, Execute, and Hidden attributes for directories and files. NSS does not use the Group ID field. Group ids associated with POSIX have no effect on files stored on NSS.
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 NSS directory and file attributes, according to the way NSS maps them to the User, Group, and Other permission fields.
By default, NSS sets the POSIX permissions fields for directories to 0777 (drwxrwxrwx). Some Linux services specify permissions needed to use the service. NSS provides the nss /PosixPermissionMask=mask option that allows you to change the default POSIX permissions, such as for the Group or Other fields.
For example, SSH requires that the POSIX permissions on home directories be set so that the Other field has no permissions. When you use NSS volumes as home directories, you must change the permission to 0770 on the home directories. You can use the nss /PosixPermissionMask=0770 command in the NSS Console (nsscon) to modify the permissions.
For information and examples of how to interpret POSIX settings on your NSS volume on Linux, see Viewing Key NSS Directory and File Attributes as Linux POSIX Permissions
in the OES 2 SP3: File Systems Management Guide.
Novell Linux User Management is a directory-enabled application that simplifies and unifies the management of user profiles on Linux-based platforms.
IMPORTANT:LUM is not required for access via NCP, Novell AFP, and Novell CIFS.
Linux-enabled eDirectory users have both UIDs as local Linux users and GUIDs as eDirectory users. NSS needs the UID to execute protocols and services that communicate to NSS through the VFS layer only. 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 Linux 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 finds the GUID for the user who issues the command, then executes the command. Without LUM, NSS cannot identify a GUID for the UID it receives, and rejects the command with an error.
For information about installing and configuring LUM, enabling Linux services and utilities, and enabling users and groups for Linux, see the OES 2 SP3: Novell Linux User Management Administration Guide.