| Message ID | 20090731100658.6bf07520@tlielax.poochiereds.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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> >
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.
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,
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