For NetWare, the Connection Manager module (connmgr.nlm) builds a connection table when a user connects to the file system. When a file is requested from either the NSS file system or the NetWare Traditional file system, the Connection Manager gathers information for the connection table from the eDirectory Services module (ds.nlm) in the form of a connection table comprised of the eDirectory EIDs for the object, for group memberships, and for security equivalences.
When the connection is established, the information in the connection table is relatively static unless the connected user is added to a new group or is given an explicit trustee assignment or security equivalence. In those situations, the connection manager updates the connection table and sends out an event that the table has changed. NSS uses this event to update its own connection table.
For the NetWare Traditional file system, the table of EIDs is all that is needed to proceed with authentication. After eDirectory provides the list of EIDs, the Connection Manager compares the list to the Directory Entry Table (DET) for the Traditional volume. It determines valid trustees by looking at the assigned trustees in the directory structure above (for trustee inheritance) and at the target file system object (for explicit trustee assignments). Inherited Rights Masks (IRMs) are also taken into consideration.
For the NSS file system, the NSS connection table establishes an entry for a user when the regular connection table entry is created, rather than at the file system access time. Logically, the NSS connection table is part of the connection table with NSS-specific information, including the eDirectory object’s GUID.
NSS uses GUIDs as the key for trustees. It keeps its own connection table with these GUIDs and compares it with the beast object entry to look for valid trustees. It finds valid trustees by looking at assigned trustees in the directory structure above (for trustee inheritance) and at the target file system object (for explicit trustee assignments), also taking IRMs into consideration.
If this fails to provide a method of access, NSS then checks the Visibility list to see if the requested object is a parent directory that requires visibility due to a rights assignment for a child directory. For information about the Visibility list, see Section 8.2.2, Visibility Lists.
When GUIDs are used instead of EIDs, it does not matter which server you are on, provided it is in the same tree, which is why Novell Cluster Services uses NSS pools and volumes.
NSS does not directly access the connection table. However, it does make calls to read information from it to form its own connection table with GUIDs and file-system trustee rights. For information about trustee rights, see Section 8.2, File-System Trustee Rights.