Bug 4644 - permissions generated by umask given to incorrect uid
Summary: permissions generated by umask given to incorrect uid
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:
Depends on:
Reported: 2007-05-21 09:55 UTC by jan vereecke
Modified: 2010-03-30 13:49 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description jan vereecke 2007-05-21 09:55:59 UTC
distribution = gentoo
uname -a = Linux Zeus 2.6.18-suspend2-r1 #2 PREEMPT Sun Mar 4 21:41:00 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
modinfo cifs | grep version =
version:        1.45
srcversion:     4D64B46EB6E08A6AD6F56B2
samba 3.0.24

in /etc/fstab
//Venus/D_ /mnt/D cifs
0 0
# Venus is a Windows XP home machine, sharing D_ using 'Simple Sharing' (which
as I understand gives rw access to anybody, including guest.)

Steps to reproduce:
(as some user on the client)
cd /mnt/D
mkdir test6
ls -ld test* # in previous attempts I had already created the other testx
drwxrwx--- 1 root smb     0 Feb 28 21:50 test3/
drwxrwx--- 1 root smb     0 Feb 28 21:52 test4/
drwxrwx--- 1 root smb     0 Feb 28 21:52 test5/
drwxr-xr-x 2 root smb     0 Feb 28 21:52 test6/
ls -ld test* # I can repeat the command as many times as I want, without the
permissions of test6 being different from 755, although I had expected 770
# 755 is in fact the result of umask 0022 on the client 

ls -ld test6
drwxrwx--- 1 root smb 0 Feb 28 21:52 test6/
# WOW, permissions suddenly changed

ls -ld test*
drwxrwx--- 1 root smb 0 Feb 28 21:50 test3/
drwxrwx--- 1 root smb 0 Feb 28 21:52 test4/
drwxrwx--- 1 root smb 0 Feb 28 21:52 test5/
drwxrwx--- 1 root smb 0 Feb 28 21:52 test6/
# and they remain changed as of now !!

I tried the above mentioned commands, but using different umasks on the
client. I saw that when a directory is created, the (incorrect) permissions
it gets are the ones specified by the umask, not the ones specified by the
dir_mask from the mount command. The problem lies in the fact that the same
thing does not happen with the user/group id. There, the options specified
in the mount command are appied immediately. This leads to a status where
permission for the creating user are applied to the userid of the mount
command instead.

In detail I think this happens:

1. The client creates a directory: the samba protocol sends that to the
server, who actually creates the directory using local rules (probably with
owner guest/everybody).

2. The cifs client remembers (caches) it created the directory with the
umask of local user, but forgets (not-cached) that uid, and applies the
mount specified uid instead. Therefore a umask specifying 'only the local
user may write' now effectively says 'only the userid specified on the mount
command may write'. This effectively prevents the creating user from
accessing its own directory. I believe this is a bug, and should be
An ls -l command shows 2 hard links, which would correspond to the cached
info and the uncached info being not equal.

3. Only some commands require the client to query the server again. Only as
of that moment, does the client read from the server that the directory
exists, and that it should be presented with the permissions as specified in
the dir_mask. It throws away the incorrect cached info (thereby reducing the
number of links), and applies the permissions that match the uid in the
mount command, which now say 'users in the group (which happens to include
the creating user) have write access'

In my opinion, one of two possible behaviours should be implemented:

A. the client caches not only the umask permissions, but also the creating
user. As long as the server data has not been re-read, it looks as though
the creating user has access rights according to the umask. the mount
uid/gid is only applied when the mount dir_mask is applied.

B. permissions are not cached and dir_mask is applied immediately.

Maybe such a behaviour is already implemented, and it may be possible to
specify what the cifs client does by activating some option in the mount
command. However, I was unable to find any such option.
Comment 1 Frank Kirchner 2008-02-05 11:13:07 UTC
Hi @all,

i'd like to know if there is a solution/fix/workaround for the caching bug.
we use debian linux.

thank you,
Comment 2 shirishpargaonkar@gmail.com 2010-02-08 17:37:47 UTC
Is this still a problem?  I just tested this scenario with a latest cifs
module against a Windowx XP exported share and the directories are 
created with correct permissions i.e. 770.
Comment 3 Steve French 2010-03-30 13:49:04 UTC
Should be fixed now for quite a while