[linux-cifs-client] Re: [PATCH] [CIFS] when creating new inodes, use file_mode/dir_mode on mount without unix extensions

[Steve French (smfltc)]

Jeff Layton wrote:

>On Tue, 22 Jan 2008 18:39:10 -0600
>"Steve French (smfltc)" <smfltc at us.ibm.com> wrote:
>
>  
>
>>Jeff Layton wrote:
>>
>>    
>>
>>>Hi Steve,
>>>  I originally sent this patch in late September. We discussed it a
>>>bit and you thought it was best to wait until most of the cifsacl
>>>patches were in. Now that they are, I'd like to have this patch
>>>reconsidered. It just makes it so that file and dir modes are not
>>>temporarily overridden when a new inode is created.
>>>
>>>I've tested it using my modified cthon04 test on a CIFS mount to
>>>samba with unix extensions disabled. Everything seems to work as long
>>>as you pick sensible file_mode/dir_mode settings. The default
>>>file_mode makes it fail, however -- it seems that cthon04 doesn't
>>>care for mandatory locking.
>>>
>>>Thoughts?
>>> 
>>>
>>>      
>>>
>>This seems risky in a few ways.  With your patch an application which 
>>wants to restrict the mode of a new file which is creates, ie to less 
>>than the default mode for the share, would no longer be able to.  In
>>the local case you may have a mask that lets you get a different mode
>>than you requested, but the result would be less than what you ask
>>for (never more than what you asked for on the create).
>>    
>>
>
>
>Right, but it's also possible that the reverse is true -- someone could
>specify a restrictive file_mode/dir_mode and assume that when they
>create a file that they'll get that mode regardless of what option is
>mode is specified in the create call.
>  
>
If we want to treat the mode on the mount like a second mask, that is 
fine, but we may want
to make that configurable.

I would expect a lot of applications (not just ltp tests) would fail to 
mounts to Windows server if they create files with various different 
modes and they all end up getting the same mode (due to only using the 
mode on mount) even taking into account that we can handle removing 
write mode via +R dos attribute.

I have been assuming that the new cifsacl mount option(CIFS acl to mode 
mapping)  could be too slow for some workloads (and it is still 
experimental), but it does fix the issue of having the right mode that 
the application asks for.  Do we need another mount option to indicate 
whether we want to use the mode specified on the mount or as we do today 
use the specified mode on lookup of existing inodes but do our best 
effort on chmod/mkdir/create?

>>It also
>>seems like we go from a case in which the mode is correct for quite a
>>while (but then could revert back to the default for the share when
>>the inode is flushed/reloaded), to a case in which the mode is never
>>right.   The original idea was that revalidate was not supposed to
>>change the mode for a file if the application had set a specific mode 
>>(create/mkdir/chmod).  There were cases in which the inode info would 
>>get flushed because e.g. the file were not still open and there were 
>>memory pressure - and in these cases the inode's mode would look 
>>different on next lookup, but at least it would be correct for a long 
>>time (and this is no different than what Unix applications deal with 
>>everyday - a file's mode could change at any time on the server so 
>>applications have to deal with this already).
>>    
>>
>
>It all comes down to what is the behavior of least surprise. IMO,
>if someone specifies a file_mode/dir_mode then that's what they should
>expect in all cases, not just when the cached inode metadata times out.
>
>  
>
It should not relate to when the metadata times out - if we set the mode 
locally (but can't set
it remotely) we should never overwrite the mode for the same 
in-memory-inode from the remote
server.  We may have a bug here.

>The main problem with this is that we're just talking about the mode.
>What about the uid/gid? While the mode is respected here, the uid/gid
>of the user creating the file is not. This causes problems like this:
>
>  
>
This is worth investigating/exploring...