In a discussion with several other people in the support forums at: http://forums.novell.com/novell-product-support-forums/edirectory/edir-netware/311341-edirectory-objects-losing-file-system-rights.html, a number of experts and me, we could not agree on how exactly file system trustees for deleted objects were handled in NetWare. This made me do some more in depth research which lead to the discovery that things were even different from what any of thought and each of us had at least been partly wrong. Given that knowing the exact underlying behaviour is important for debugging some problems and for understanding security issues which might arise from reinstalling NDS or from moving a volume between servers, I wrote this article so that as many people as possible can take advantage of my little research.
1. Some terminology
EID: Entry ID (also sometimes called local ID)
The EID is a 32 bit number by which a server addresses NDS objects locally. The EID is used in many places, and in the context of the file system, all APIs that handle file system trustees do so by identifying NDS objects by their EID. EIDs are always local to a server. The same NDS object will typically have different EIDs on different servers.
On RECMAN versions of NDS (e.g. up to NDS 7.x), the lower 24 bit of the EID are the index of the object in the entry table. The upper 8 bits are a reuse counter. In other words, each time a same entry record is reused for a different object, the use counter is increased. This ensures that the same EID number is (virtually) never reused. Without this safeguard for instance, deleting an object and then creating a new one could have caused the new object to get the same EID as the deleted object and could potentially create security issues.
On FLAIM versions of NDS/eDirectory (e.g. NDS8 or higher), EID is simply a number starting at 0x8000 and incremented each time a new object appears in the local database. The EID values of deleted objects are never reused.
GUID: Global Unique ID
Starting with NetWare 5.0, Novell has introduced the GUID as an object ID and the GUID is generated such that by design, it should in theory by unique in the world. While introduced in NetWare 5.0, it is only with NetWare 6.0 that Novell has really started to take advantage of the GUID by using it as a way to identify an NDS object in the file system and thus make the file system more “portable” between different servers in the same tree. This is essential for being able to efficiently support clusters where the same volume must be able to be mounted on different servers while keeping the trustees the same.
2. How trustees are stored in the file system
TFS and NSSv2
On the traditional file system (TFS) as well as on NSS 2.x (the version used on NetWare 5.x), Novell uses the EID to store trustees, file ownership and any other object references in the file system. Given that EIDs are strictly local to a server, trustee assignments only remain valid as long as the volume remains attached to the same server.
With the introduction of NetWare 6.0, Novell updated NSS to version 3 and changed the way trustee assignments, file ownership etc. are stored in the file system. The EID is no longer used, but now the GUID is used instead. This makes the NDS relationship independent of the server the volume is attached to and NSS formatted disks can be moved between servers without loosing rights or file ownership. However, as already indicated before, all APIs and all internal working remains EID based. For this reason, NSS includes an ID cache which is built at mount time and which maps GUIDs to EIDs. This allows NSS to quickly map EIDs to GUIDs and vice versa.
3. How the server handles the deletion of objects that are trustees to the file system
TFS and NSS v2
When deleting an object, trustees on TFS volumes are deleted, but only if the volume is mounted at the time of the deletion.
Invalid trustees that are not deleted for some reason remain visible in various tools and produce -601 errors in tools like trustee.nlm or
Invalid trustee do not cause security issues under normal circumstances because EID numbers should never be reused on the same server. If however the NDS is reinstalled or if the volume is moved to a different server, then the EIDs might suddenly correspond to existing different objects and thus other users might receive rights.
Trustees in NSS volumes are *not* immediately deleted. However as soon as the objects are completely gone, the GUID to EID mapping is removed from the IDCache and as a result, the trustees become invisible through normal APIs. Once the GUID to EID mapping is gone, the invalid trustees can only be seen by tools that address NSS directly to show the GUID information. One such tool is DMPTRUST.NLM. DMPTRUST.NLM will show the GUIDs and associated rights for objects that no longer exist. However to avoid the accumulation of dead trustees, NSS has a background process that cleans up dead trustees. This process is explained in the section “Background Trustee Check” at the bottom of the following article: http://support.novell.com/techcenter/articles/ana20030202.html
Dead trustees should never be a security issue because the way GUIDs are generated should in theory make them unique in the world and as such,
trustees should never end up being associated with a different object.
4. Upgrade considerations
Upgrade from NDS7 to eDirectory 8 or later on a TFS volume.
This scenario typically happens when upgrading a NetWare 5.x server from NDS7 to a newer NDS version, but also for in place upgrades from NetWare 5.0 with NDS7 to NetWare 5.1 or in place upgrades from NetWare 5.x with NDS7 to NetWare 6.x.
As described in section 1, the EID format is fundamentally different between NDS7 and eDirectory. Because of this, an upgrade from NDS7 to eDirectory will cause all EIDs to change. This is of course a major problem for trustee assignments that are based on EIDs (e.g. like on TFS or NSSv2 volumes). Therefore, during the NDS database upgrade path, the install program creates a table to match the old EIDs to the new EIDs. Then, once the NDS itself has been migrated, the installation program goes through all volumes and for each volume it replaces all the old EIDs by the new ones. This includes EIDs used for the volume object, for trustee assignments as well as for file ownership. Because of this, it is essential that all volumes or mounted during the upgrade process or else, the volumes that are not mounted will not have their EIDs swapped.
Upgrade from NSSv2 to NSSv3.
This scenario happens when upgrading a NetWare 5.x server with NSS volumes to NetWare 6.x. As already indicated in section 1, trustees are stored as EIDs on NSSv2 and as GUIDs in NSSv3. Because of this, after upgrading the media format from NSSv2 to NSSv3, the installation program has to scan all EIDs found in the file system and replaces them with the GUIDs for the corresponding objects.
For both upgrade scenarios, there is a trustee mapping pass and if that pass does not correctly execute, then trustee assignments and file ownership are lost. Because of this, it is highly recommended to save trustee assignments and file ownership with a tool like TRUSTEE.NLM prior to the migration. Because TRUSTEE.NLM uses object names and not EIDs or GUIDs, the file produced by TRUSTEE.NLM can easily be used to restore trustee assignments and file ownerships after an upgrade that partially failed.
Invalid trustees on TFS can be removed with trustee.nlm and dsrepair.nlm.
Invalid trustees on NSS are deleted by the NSS background check.
Conventional tools don’t see invalid trustees on NSS because they become invisible as soon as the EID/GUID mapping disappears. Neither TRUSTEE.NLM nor DSREPAIR.NLM will remove invalid trustees from NSS volumes
trustee.nlm and trustbar.nlm can report valid trustees on any kind of volumes. These tools produce -601 errors for invalid trustees on TFS and
will not see invalid trustees on NSS except during a small window of time were the object is marked deleted but has not yet been purged
dmptrust.nlm can be used to report all trustees on NSS volumes showing the GUID for each trustee, and if available, also the EID and full object name.
6. What’s next
This article only deals with trustee assignments on NetWare. On OES/Linux, things are a bit more complicated because the NCP server allows trustee assignments on Linux file systems. Describing how this is done would be a good topic for a next article.