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

[simo]

On Wed, 2008-01-23 at 12:39 -0600, Steve French (smfltc) wrote:
> >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...

FYI, I just got a report on an Italian mailing list about problems
created by this ephemeral mode.

This user complains that he can create files but they become immediately
unusable to him, but *only* on the linux machine that creates them.
Accessing the file from another linux machine is fine.

This is because the cifs.mount default use is root and the mode being
set makes it impossible for the user to access the file.


A short excerpt from his email:

        questi sono i permessi di un file appena salvato, che al momento
        non 
        riesco a modificare:
        ls -hl /media/pub/test.doc
        -rw-r--r-- 1 root root 145K 2008-01-31 16:21 /media/pub/test.doc
        
        questi i permessi come li vedo da altro pc linux
        
        ls -hl /mnt/pub/test.doc
        -rwxrwSrwt 1 root root 145K 2008-01-31 16:21 /mnt/pub/test.doc
        

The first listing comes from the machine where the file was created.
The second is the same file from another machine.

The fact that 2 machines see different permissions is bad enough, the
fact a user can't access a file just created is *dangerous*.
What if I put my credit card number by mistake and can't access the file
to delete it ASAP ?

Not counting the fact that as the file get root permissions I see many
other potential dangerous things that may go on. What if the original
user manages to add the setuid bit to his mode?
Will the file become root setuid ?

I think we need to solve this properly asap.
And also make it sure that, by default only the mounting user can access
the files at all, default mode should be masked 0700 IMO, letting non
authenticated users access files they do not own by default (yes even
root) is a violation of the security model of the target server IMO.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>