[linux-cifs-client] review 5, was Re: projected date for mount.cifs to support DFS junction points

[Steve French]

On Sat, Mar 8, 2008 at 1:43 PM, Christoph Hellwig <hch at infradead.org> wrote:
> On Mon, Feb 25, 2008 at 02:25:50PM -0600, Steve French wrote:
>  > On Fri, Feb 15, 2008 at 4:11 PM, Christoph Hellwig <hch at infradead.org> wrote:
>  Okay, now that we have the basic consolidation in can I get you to
>  review force_uid_gid paramter to cifs_unix_info_to_inode?  It seems
>  more than fishy to me to ignore the CIFS_MOUNT_OVERR_{UID,GID} options
>  in cifs_get_inode_info_unix but not in posix_fill_in_inode.  This
>  seems more like a missed propagation of changes for a newly added
>  feature to me.  If not it should at least get some documentation.

Jeff Layton and I have been discussing the issue of which uid to use
to fill in the inode->i_uid and I am leaning toward changing the
default behavior (for the mount to Windows server case) and adding
another mount parm to allow users to get the older behavior if they
want.

Unfortunately there are many cases (and the uid/gid owner fields of
inodes can get filled in potentially in various places
mkdir/create/mknod and lookup and readdir and of course setattr).  The
mount could be to:
1) server which support returning uid/gid owner fields for an inode
(e.g. Samba) on QueryPathInfo
2) servers which would support returning a uid, but for which the uids
on the server don't match the client
3) servers like Windows which don't support returning the inodes uid

and for the latter we also have the case of files/directories for
which the user has chowned it so we know what uid the app thinks it
should be (or newly created files/directories)

Some of this is documented, and I have started a table which needs to
be added to the CIFS User's guide - but the case I am most worried
about at the moment is the behavior when the server would support the
Unix extensions - but the user has overridden the uid or gid
(specified on mount, perhaps because the server and client's uids
differ).   For this case should we always use the default uid - or
should an app be allowed to do a chmod and should we honor the uid/gid
passed in on the mkdir/create/mknod (as we do for the equivalent
windows case).




-- 
Thanks,

Steve