[linux-cifs-client] [PATCH 0/5] [CIFS] add new mount option to control "dynamic" mode setting

Jeff Layton jlayton at redhat.com
Mon May 12 15:01:10 GMT 2008


On Mon, 12 May 2008 10:49:32 -0400
Jeff Layton <jlayton at redhat.com> wrote:

> Hi Steve,
> 
> Here's a respin of the unapplied patches to fix the "ephemeral modes"
> problem. This set adds a new "dynperm" mount option. When unix
> extensions aren't negotiated and cifsacl isn't turned on, this makes the
> modes "float". Mode changes will have no effect on the server and will
> exist in memory only.
> 
> This is a little different from the current behavior, which would try to
> make the write bits on the file track ATTR_READONLY in some cases. We
> could make it so that this still happens when we use dynperm, but I'm
> not sure what to do in the following case:
> 
> Suppose we have a CIFS mount with file_mode=02767, and we change the
> mode to something like this (which turns off ATTR_READONLY on the
> server):
> 
>     # chmod 0400 testfile.txt
> 
> ...now, suppose someone turns on the ATTR_READONLY bit on the server.
> What write bits should be reenabled? Turning them all on (per the
> default file_mode) would seem to be contrary to the wishes of the user.
> 
> Signed-off-by: Jeff Layton <jlayton at redhat.com>

Sorry, 
  I should not have posted this before having my coffee this morning.
The initial mode change should turn *on* ATTR_READONLY, and then
someone turns it *off* on the server.

Still, my question stands, when someone turns off the ATTR_READONLY bit
on a file on a "dynperm" share, what write bits should we reenable?

This is why I took the simple way out and decided to just not deal with
ATTR_READONLY in this case, but I'm not dead-set on that scheme.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list