Patchwork Follow on patches for uid=/gid= behavior changes

login
register
mail settings
Submitter Jeff Layton
Date July 31, 2009, 2:06 p.m.
Message ID <20090731100658.6bf07520@tlielax.poochiereds.net>
Download mbox | patch
Permalink /patch/30430/
State New
Headers show

Comments

Jeff Layton - July 31, 2009, 2:06 p.m.
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?
Steve French - July 31, 2009, 3:04 p.m.
The README update seems ok (although a little long, I didn't see an obvious
way to shrink it).   I am not convinced that we want to add the warn about
kernel behavior change (may be able to do this in mount.cifs more sensibly,
or not change the behavior if users turn out to prefer this way)

On Fri, Jul 31, 2009 at 9:06 AM, Jeff Layton <jlayton@redhat.com> wrote:

> 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?
>
> --
> Jeff Layton <jlayton@redhat.com>
>
Jeff Layton - July 31, 2009, 3:32 p.m.
On Fri, 31 Jul 2009 10:04:07 -0500
Steve French <smfrench@gmail.com> wrote:

> The README update seems ok (although a little long, I didn't see an obvious
> way to shrink it).   I am not convinced that we want to add the warn about
> kernel behavior change (may be able to do this in mount.cifs more sensibly,
> or not change the behavior if users turn out to prefer this way)
> 

Yeah, that's really my question at this point. Should we change the
default behavior?

I think it ultimately makes more sense to not clobber the ownership
unless it's specifically requested. As my evidence I submit the manpage
update -- there are more "ifs" and special cases when explaining the
the option behavior.

OTOH, it's a lot more effort to change the default. Maybe it's not
worth it.

Another idea: would it be better to dispense with forceuid/forcegid and
just add a new default_uid= or default_gid= options to specify what the
owner should be when one isn't provided (and when uid=/gid= aren't
specified).

Given that my first pass at this made everyone unhappy, I'd appreciate
some feedback.
Suresh Jayaraman - Aug. 3, 2009, 9:34 a.m.
Jeff Layton wrote:
> On Fri, 31 Jul 2009 10:04:07 -0500
> Steve French <smfrench@gmail.com> wrote:
> 
>> The README update seems ok (although a little long, I didn't see an obvious
>> way to shrink it).   I am not convinced that we want to add the warn about
>> kernel behavior change (may be able to do this in mount.cifs more sensibly,
>> or not change the behavior if users turn out to prefer this way)
>>
> 
> Yeah, that's really my question at this point. Should we change the
> default behavior?

I think yes. As suggested by Andrew in the bugzilla (leave old behavior,
add new options -> let users start using new options -> deprecate old
behavior and your patches are already doing this I think). And yes,
tradionally breaking existing behavior is frowned upon by kernel
community but, perhaps for a good reason.

And I agree with Steve on adding Kernel warning. Do we really need to
add a Kernel warning? Would it be sufficient if we warn in mount.cifs? I
think we normally don't warn user about upcoming changes in dmesg.. (and
user may not look at dmesg for such behavioral changes)

> I think it ultimately makes more sense to not clobber the ownership
> unless it's specifically requested. As my evidence I submit the manpage
> update -- there are more "ifs" and special cases when explaining the
> the option behavior.
> 
> OTOH, it's a lot more effort to change the default. Maybe it's not
> worth it.

This sounds like the correct thing to me.

> Another idea: would it be better to dispense with forceuid/forcegid and
> just add a new default_uid= or default_gid= options to specify what the
> owner should be when one isn't provided (and when uid=/gid= aren't
> specified).

Too many options, wouldn't confuse users more, than helping?

> Given that my first pass at this made everyone unhappy, I'd appreciate
> some feedback.
> 


Thanks,

Patch

From a7708d4775a7f5789742baf832d25e4dfd45be59 Mon Sep 17 00:00:00 2001
From: Jeff Layton <jlayton@redhat.com>
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 <jlayton@redhat.com>
---
 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.
 		<listitem>
 
 	<para>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
 	<listitem>
 
 		<para>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.</para>
 
-	<para>When the client and server negotiate unix extensions,
+	<para>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.</para>
 
-	<para>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.</para>
+	<para>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.</para>
 
 	<para>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