mechanisms for client to determine which username a server uid represents

[Steven French]

> Maybe I'm being dense here but please explain to me
> how your solution addresses mapping uids ot name

It does not really address that.

The narrower issue I was trying to address is that of mounts from one
client e.g. to two Samba servers who don't have the same uids.  In
particular if the client has two mounts:

/mnt/A -> ServerA/ShareA   uid 100=stevef, uid 101=jerry, uid 300=guest

/mnt/B -> ServerB/ShareB   uid 100=jerry, uid 200=sfrench, uid 400=guest

No matter how winbind would be configured on the client, I don't see how it
can return the right username for a file with a uid of 100 - it will either
be wrong on the files under /mnt/A or wrong on the files on /mnt/B and the
vfs permission checks will also be wrong (if enabled on the client) since
the owner field (the kernel_uid_t and kernel_gid_t for inodes) is
presumably not something you can override in userspace.

The readdir (ls) and lookup (stat) will return uids/gids (which the server
sent in the trans2 responses for the Unix extensions) which are in a
different 'uid namespace" than the client and get strange results, although
a somewhat sane mapping of some of the users could have been done on the
client.   Even if server A were running pam/nss_ldap or winbind or had
forced the uids (via manual configuration on each client and server in
domain A) to be identical, there are always servers outside of your domain
for which the uids returned by ls/readdir of e.g. server B will make no
sense.   I doubt that winbind can help you translate a name for uid 1001,
if you have no such uid, but it might make sense for the cifs vfs (or nfs
v3 client for that matter) to translate all uids in a particular  range (or
all but a few uids) on that mount to a default uid which is valid locally
on the client (nfs on other platforms, other than Linux, apparently has
historically such uid mapping services although sometimes done on the nfs
server by the server (!) contacting the clients mapping daemon before
returning results).  NFSv4 solves this by returning uids as names rather
than numbers in the wire protocol and letting the client call a
fully_qualified_username->local_uid mapping service on the client.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot c