Steven French sfrench at us.ibm.com
Fri May 20 14:29:45 GMT 2005

It looks like the new unixinfo rpc pipe could give Samba domains a big
benefit even if Windows servers are in the same domain - it would give our
clients for the first time the infrastructure necessary to map sids to
linux/unix uids for the important case of  Windows servers in a  Samba
domain (or in general servers that don't support the Unix extensions in a
Samba domain).   We still have the same problem with not being able to
return both uid_t and gid_t owner but it may be useful even so.   There may
be OS where this does not work as uid_t may not be 32 bits on all OS.

What I am thinking of is

1) Mount to server from linux cifs vfs
2) mount succeeds but server does not support the Unix extensions
3) depending on mount option, augment lookup login in the cifs kernel
module with additional call to get owning SID for file/directory (hopefully
there is a QueryPathInfo level for this without having to retrieve the
whole ACL).
4) upcall to samba tool that can invoke the client side of sid->uid
5) pass down the results (uid_t or gid_t) to the kernel cifs vfs code
6) depending on whether sid represented group or user, update the uid_t or
gid_t field of the inode

1) on chown (setattr), upcall to a client userspace util that calls the
unix info pipe to do uid->sid for the new uid_t for the inode
2) pass back the sid to the kernel code
3) have kernel code set the sid in the ACL

What versions of Samba will this pipe be in?  I only see Samba 4 so far and
depending on Samba 4 code complicates the kernel utils, but it could be
made optional easily enough.

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

More information about the samba-technical mailing list