[Samba] permissions on samba share change automatically

[jan vereecke]

On the problem summarized below, I have some additional information, and
what I believe is a bug in the cifs client. Can anyone advise on how/where
to file the bug report ?

I found out what is the probable cause of the problem above, but not what
the solution is.

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
corrected.
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.



================================================================
I have a problem executing certain actions on a share, which is shared by a
windows XP Home machine and mounted by a linux machine

First of all some information:

in /etc/fstab
Quote:
//Venus/D_ /mnt/D cifs
users,gid=smb,file_mode=0770
,dir_mode=0770,iocharset=iso8859-15,credentials=/etc/samba/credentials
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.)

if I open xterm, I can do

Code:
cd /mnt/D
mkdir test6
ls -ld test* # in previous attempts I had already created the other testx
directories
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 750, although I had expected 770

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 !!


Anyhow, I believe this must be a problem with the way cifs has been setup.
Can anyone explain what is happening here ?