[linux-cifs-client] [PATCH 1/3] cifs: make overriding of ownership conditional on new mount options

Jeff Layton jlayton at redhat.com
Thu Jun 4 17:15:29 GMT 2009


On Sun, 24 May 2009 18:45:15 -0400
Jeff Layton <jlayton at redhat.com> wrote:

> We have a bit of a problem with the uid= option. The basic issue is that
> it means too many things and has too many side-effects.
> 
> It's possible to allow an unprivileged user to mount a filesystem if the
> user owns the mountpoint, /bin/mount is setuid root, and the mount is
> set up in /etc/fstab with the "user" option.
> 
> When doing this though, /bin/mount automatically adds the "uid=" and
> "gid=" options to the share. This is fortunate since the correct uid=
> option is needed in order to tell the upcall what user's credcache to
> use when generating the SPNEGO blob.
> 
> On a mount without unix extensions this is fine -- you generally will
> want the files to be owned by the "owner" of the mount. The problem
> comes in on a mount with unix extensions. With those enabled, the
> uid/gid options cause the ownership of files to be overriden even though
> the server is sending along the ownership info.
> 
> This means that it's not possible to have a mount by an unprivileged
> user that shows the server's file ownership info. The result is also
> inode permissions that have no reflection at all on the server. You
> simply cannot separate ownership from the mode in this fashion.
> 
> This behavior also makes MultiuserMount option less usable. Once you
> pass in the uid= option for a mount, then you can't use unix ownership
> info and allow someone to share the mount.
> 
> While I'm not thrilled with it, the only solution I can see is to stop
> making uid=/gid= force the overriding of ownership on mounts, and to add
> new mount options that turn this behavior on.
> 
> Signed-off-by: Jeff Layton <jlayton at redhat.com>
> ---
>  fs/cifs/connect.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 4aa81a5..4f5a03c 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -1092,17 +1092,17 @@ cifs_parse_mount_options(char *options, const char *devname,
>  				return 1;
>  			}
>  		} else if (strnicmp(data, "uid", 3) == 0) {
> -			if (value && *value) {
> +			if (value && *value)
>  				vol->linux_uid =
>  					simple_strtoul(value, &value, 0);
> +		} else if (strnicmp(data, "forceuid", 8) == 0) {
>  				vol->override_uid = 1;
> -			}
>  		} else if (strnicmp(data, "gid", 3) == 0) {
> -			if (value && *value) {
> +			if (value && *value)
>  				vol->linux_gid =
>  					simple_strtoul(value, &value, 0);
> +		} else if (strnicmp(data, "forcegid", 8) == 0) {
>  				vol->override_gid = 1;
> -			}
>  		} else if (strnicmp(data, "file_mode", 4) == 0) {
>  			if (value && *value) {
>  				vol->file_mode =
> -- 
> 1.6.0.6
> 


Steve,
   Any word on this patch? I have a customer who is being impacted by
this bug. I need to bring it to some sort of resolution soon.

Thanks,
-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list