Bug 3593 - Cifs kernel module; does not honor umask when acls are enabled
Summary: Cifs kernel module; does not honor umask when acls are enabled
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: x86 Linux
: P3 normal
Target Milestone: ---
Assignee: Steve French
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-08 20:37 UTC by Jonathan Bastien-Filiatrault
Modified: 2009-05-15 11:08 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Bastien-Filiatrault 2006-03-08 20:37:53 UTC
What happens:
$ umask 777
$ touch afile
> The file has a mode of 644

What should happen:
$ umask 777
$ touch afile
> The file should have mode 000

Share definition:
[userdata]                                                                      
    comment = Homes                                                             
    writable = yes                                                              
    path = /srv/drbd/home                                                       
    map archive = no                                                            
    delete readonly = yes                                                       
    preserve case = yes                                                         
    case sensitive = yes                                                        
    short preserve case = yes

This bug is trigered when acls are enabled, mounting it with noacl produces the correct behaviour.

Side note, the setuids option is enabled and no mode overrides are present in the smb.conf file. The file server is Samba version 3.0.21c.
Comment 1 shirishpargaonkar@gmail.com 2009-03-25 09:59:15 UTC
What I am not sure is, which umask should take precedence or stand out if
- I have specified umask on the mount command on the client
- samba.conf on the server has a create mask entry
- umask on the local file system on the server (the share that samba exports)!

I am also not sure why  noacl  mount flag or absense of it should have any
impact on the mode the file is created on the server.
Comment 2 shirishpargaonkar@gmail.com 2009-03-25 11:54:58 UTC
cifstest4:/tmp/sharename # umask
0777
cifstest4:/tmp/sharename # ls -l
total 20
drwxr-xr-x 2 root   root    4096 Mar 25 05:49 cldir1
drwxr-xr-x 2 root   root    4096 Mar 25 06:03 cldir2

Somehow samba server chooses the mask of 0022.

I created these directories using smbclient.

cifstest6: # smbclient //cifstest4/sharename -U root
Enter root's password:
Domain=[CIFSTEST4] OS=[Unix] Server=[Samba 3.0.22-3-SUSE-CODE10]
smb: \> mkdir cldir2
smb: \> quit

This is the stanza in samba.conf

[sharename]
        path =  /tmp/sharename
        browseable = Yes
        read only = No
        guest ok = Yes
        writable = yes

I created a file on this share with umask of 0777 from a Windows XP client
and the file was created with permissions with umask of 0022 excpet that
user had executable bit on which is strange considering the default 
permissions before being masked with umask for a file are 666.
Comment 3 shirishpargaonkar@gmail.com 2009-03-25 23:03:52 UTC
I think it is fixed now, it is not a bug anymore, I am using 1.54 version of 
cifs vfs client.

//cifstest4/sharename /mnt/smb_a cifs rw,mand 0 0

cifstest6: # umask
0022
cifstest6: # touch /mnt/smb_a/umaskfile_0022
cifstest6: # ls -l /mnt/smb_a/umaskfile_0022
-rw-r--r-- 1 root root 0 Mar 25 22:55 /mnt/smb_a/umaskfile_0022

cifstest6: # umask 0777
cifstest6: # umask
0777
cifstest6: # touch /mnt/smb_a/umaskfile_0777
cifstest6: # ls -l /mnt/smb_a/umaskfile_0777
---------- 1 root root 0 Mar 25 22:55 /mnt/smb_a/umaskfile_0777

So the umask of the process on the client which creates a file
is taken into consideration.
Comment 4 shirishpargaonkar@gmail.com 2009-03-26 09:32:57 UTC
with 1.55 version of the cifs, I see correct permissions on the files on 
the samba shares as per the umask of the process on the client that creates 
these files

-rw-r--r-- 1 root root 0 Mar 26 03:23 cft4.0022
--w-r--r-- 1 root root 0 Mar 26 03:24 cft4.0522
--w--w-r-- 1 root root 0 Mar 26 03:36 cft4.0552
Comment 5 shirishpargaonkar@gmail.com 2009-03-26 13:50:27 UTC
Yes, this is not a bug anymore, it is fixed in later version of cifs such
as 1.55.
Comment 6 Steve French 2009-05-15 11:08:08 UTC
yes - verified that it is fixed now