From patchwork Fri Jul 31 14:06:58 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Follow on patches for uid=/gid= behavior changes Date: Fri, 31 Jul 2009 04:06:58 -0000 From: Jeff Layton X-Patchwork-Id: 30430 Message-Id: <20090731100658.6bf07520@tlielax.poochiereds.net> To: smfrench@gmail.com Cc: linux-cifs-client@lists.samba.org If the patch I posted this morning looks OK, here's a proposed README patch, and a patch to the mount.cifs manpage. Finally, here's a third patch that adds a warning about the change for the default behavior for 2.6.33. Thoughts on all 3? >From a7708d4775a7f5789742baf832d25e4dfd45be59 Mon Sep 17 00:00:00 2001 From: Jeff Layton Date: Fri, 31 Jul 2009 09:19:32 -0400 Subject: [PATCH] manpage: update the mount.cifs manpage to reflect changes when uid= or gid= is specified The change to not override ownership information when uid= is specified was considered a regression so the older default behavior had to be restored. Update the manpage to reflect the current situation in-kernel. Signed-off-by: Jeff Layton --- docs-xml/manpages-3/mount.cifs.8.xml | 23 +++++++++++++---------- 1 files changed, 13 insertions(+), 10 deletions(-) diff --git a/docs-xml/manpages-3/mount.cifs.8.xml b/docs-xml/manpages-3/mount.cifs.8.xml index 9383f3f..b8b7b50 100644 --- a/docs-xml/manpages-3/mount.cifs.8.xml +++ b/docs-xml/manpages-3/mount.cifs.8.xml @@ -128,8 +128,7 @@ credentials file properly. sets the uid that will own all files or directories on the -mounted filesystem when the server does not provide ownership -information. It may be specified as either a username or a numeric uid. +mounted filesystem. It may be specified as either a username or a numeric uid. When not specified, the default is uid 0. The mount.cifs helper must be at version 1.10 or higher to support specifying the uid in non-numeric form. See the section on FILE AND DIRECTORY OWNERSHIP AND PERMISSIONS below for more @@ -152,8 +151,7 @@ be the value of the uid= option. See the section on FILE AND DIRECTORY OWNERSHIP sets the gid that will own all files or -directories on the mounted filesystem when the server does not provide -ownership information. It may be specified as either a groupname or a +directories on the mounted filesystem. It may be specified as either a groupname or a numeric gid. When not specified, the default is gid 0. The mount.cifs helper must be at version 1.10 or higher to support specifying the gid in non-numeric form. See the section on FILE AND DIRECTORY OWNERSHIP AND @@ -534,7 +532,8 @@ uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. Attempting to change these values via chmod/chown will return success but have no effect. - When the client and server negotiate unix extensions, + When the client and server negotiate unix extensions +and the uid= and gid= options are not specified, files and directories will be assigned the uid, gid, and mode provided by the server. Because CIFS mounts are generally single-user, and the same credentials are used no matter what user accesses the mount, newly @@ -542,11 +541,15 @@ created files and directories will generally be given ownership corresponding to whatever credentials were used to mount the share. - If the uid's and gid's being used do not match on the -client and server, the forceuid and forcegid options may be helpful. -Note however, that there is no corresponding option to override the -mode. Permissions assigned to a file when forceuid or forcegid are in -effect may not reflect the the real permissions. + If the uid= or gid= options are provided then the +ownership of all files and directories on the mount will be overridden. +To prevent the client from clobbering file ownership information on +these mounts, use the "noforceuid" and "noforcegid" options. Note that +file modes are not overriden in this situation. Since the default +behavior is to override ownership when the uid= and gid= options are in +effect but file and directory modes are preserved, one should be cautious +when using these options since the resulting permissions may grant +unintended privileges. When unix extensions are not negotiated, it's also possible to emulate them locally on the server using the "dynperm" mount -- 1.6.0.6