Hi,

Agreed that novlxsrvd is not required anymore. Tracking to remove with upcoming OES releases.

On usage of Novell Registry, it's used for more purposes that for the values/entries contained are more than their apparent use and registry is tightly coupled with xtier. So, we will continue to have registry.

Finally, for the question "And lastly, why can those LUM-enabled services not interact directly with Edir as e.g. Netware could", LUM enabled services use eDirectory only as identity service and interact with eDirectory through LUM as required.

Lokesh

Okay, the removal of novlxsrvd in the future is good news.

That sfcb and httpstkd work as LUM-enabled services is okay, but why tsafs can't use Edirectory is not clear to me - as this is a service, which was ported from Netware to OES and therefore originally had no idea of LUM. And if I remember correctly, that was not LUM-enabled in some earlier versions of OES, too. I explicitly ask for tsafs, because this does run as root - so no need to authenticate via LUM and secondly the file-system rights for NSS-volumes cannot be translated into LUM-rights as you can give NSS-file-rights to things like OUs etc, which have no representation in LUM.

Though tsafs (smdrd) runs as root, it does backup/restore or the file/folder moves during DFS move/split or migration using miggui/migfiles as the user who initiates these operations. On Linux, unlike NetWare, access to NSS is based on the "fsuid" of the process. The tsafs sets "fsuid" of the process to the "uid" of the user before making calls to NSS. LUM provides that "uid".

Okay, I understand this approach.

But on the other hand ncp-fileaccess and cifsd are not LUM-enabled and also able to follow filesystem rights via eDir I presume. And the fsuid, which is set to the tsafs-process via setfsuid is just used by the nss-filsystem read/write processes to lookup this user in Edir to get the rights of this user. So you first create an UID for an Edir user via LUM, then set this UID as FSUID via setfsuid to the tsafs-process and then the nss-filsystem read/write processes use this FSUID to get the Edirectory user of the process, to get its filesystem rights. Wouldn't it be much more straghtforward, to directly pass the edir user of the user who invoked the tsafs to the nss read/write processes?

No, because Linux relies on fsuid (file system user id) for file access control. Not just NSS, all Linux file systems work this way.

Also, there is no application API/interface to inform a file system the name of the user. The only interface is setfsuid() which by the way is unique to Linux.

I don't know, how this is implemented in tsafs, but in cifs, ncp-connections and other daemons fsuid is not used. And only samba on DSfW server uses the UIDs but here the euid is identical to the fsuid, so the process itself runs as the user, who is accessing the file.

Ncp and cifs run as root and their fsuids are all zero=root, so they probably use the mechanisms in Linux - I think introduced with NFSv4 - to use real users for file access control instead of uid-numbers. On all servers I checked, there are no processes running with any euid, uid, fsuid of an Edir user, even if the servers are accessed via cifs and ncp.

I only see edir-user uids, with samba and if ssh is explicitly LUM-enabled and an Edir user runs a ssh-session on the server. 

NCP/CIFS run as root. However, when they have to interact with NSS on behalf a user they switch the "fsuid" to that of the respective user. When a user requests for a file system operation the thread handling that connection in CIFS/NCP do setfsuid() before doing the respective operation and then set it back to root uid (0) and continue.

I do not know, how this is implemented in OES, but I doubt, that it is working that way.

I did not find any process with a fsuid of a user (with the exception of samba on a DSFW server) on any server, but would imagine, that the processes, which handle the open file handles, will not close immediately after a read or write operation, so there should be some process, which has a fsuid of a user. Furthermore on servers, which have only the minimum of LUM installed, you can see, which NIT/LUM uids were generated (marked as NIT-generated uids, vias nitconfig. And there I found, that the only NIT- generated uids were generated by or for tsafs for all users and groups, which have explicit trustee rights assigned to the volumes backed up and for the volume itself. And I do see errors in messages, if tsafs tries to get the NIT-uid for e.g. OUs, which have trustee rights to the volume or a part of it. For the backup-user I do not see such entries.

And futhermore, if LUM is broken for some reason, ncp-file-access is not broken.