For an OES server, you can control access to services locally or with eDirectory. If the server contains Novell Storage Systems (NSS) volumes, you can control access in only one of the two methods, not both, and not a combination. The access methods are referred to as Independent mode and NetWare mode.
|
Access Control |
File System |
Local Users |
eDirectory Users |
Access Mode |
|---|---|---|---|---|
|
Local only |
Linux POSIX file systems |
Yes |
No |
xNFS Independent |
|
NCP/eDirectory, except for Root user |
Linux POSIX file systems |
No |
Yes |
xNFS Independent |
|
Local and NCP/eDirectory |
Linux POSIX file systems |
Yes |
Yes, Linux-enabled local users |
xNFS Independent |
|
Local only |
NSS |
Root user only |
No |
xNFS Independent |
|
NCP/eDirectory, except for Root user |
NSS |
Root user only |
Yes |
xNFS NetWare |
|
Local and NCP/eDirectory |
NSS |
Root user only |
Yes, Linux-enabled local users |
xNFS NetWare |
For more information about NSS, NCP Server, and Linux User Management, see the following:
In NetWare mode, NCP calculates access control permissions for three entities:
The eDirectory User object mapped to the directory or file User ID (UNIX User ID (UID))
The eDirectory Group object mapped to the directory or file Group ID (UNIX Group ID (GID))
The eDirectory Group object mapped to the directory or file Others ID (UNIX GID 65535)
These user entities are referred to as mapped users. All other users are called unmapped users.
For NSS volumes, 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, see Section 5.8, Viewing Key NSS Directory and File Attributes as Linux POSIX Permissions.
When the user connects to the system with a data request, NCP calculates the effective rights table for the user. As NCP accesses the data on an NSS volume, it compares the ID values to the user’s effective rights to determine what access is allowed. It then interprets the directory or file attributes from the NSS metadata.
The NCP server ensures that trustee rights and directory and file attributes are enforced when users access their data. To ensure that the user’s data is not less secure when accessed from the Linux environment or with other protocols, the NSS volume data tends to be less accessible when accessed locally on the Linux system or through other protocols. NCP users only have rights where they have been explicitly granted to them through trustee assignments on the volume or to the NCP server object in eDirectory so NCP does not create security back doors into other parts of the system.
NCP provides basic accessibility when the Linux-enabled authenticated user accesses the system locally or through another protocol. In order to accomplish this with file systems other than NSS, NCP sets the UID of files and directories to be that of the user who creates them. Using LUM (Linux User Management), these IDs map to valid Linux UIDs. Additionally, a local user on the Linux system could use NCPFS (ncpmount) and establish an authenticated NCP session with the NCP server, allowing the user’s local access rights to mirror the rights available remotely through NCP.
With NSS volumes, the trustee information is stored in NSS with the directory or file. NSS allows access to their file system to Linux user IDs based on what their trustee rights are in the NSS file system. If a user has an NCP-assigned trustee right to a subdirectory on an NSS volume, that same user could log in at the Linux console and have the same access locally that he or she has through NCP. Protocols such as NFS and Samba that access files with the remote client’s UID should also work well with NSS.