dos filemode: a stale lock since 3.4

[Dmitry Butskoy]

I've discovered an issue since the Samba 3.4, when "dos filemode = yes" 
and a "not-owner with write access" tries to change file attributes. A 
stale lock appear (it may vary depending on a particular user case, the 
simplified test see below).

Comparing the function  "smbd/open.c:open_file_fchmod()"  between the 
versions 3.2.15 and 3.4.8, the call of "open_file" was changed to 
"SMB_VFS_CREATE_FILE()", but the correspond  
"smbd/open.c:close_file_fchmod()"  seems not changed in this way. I 
guess this change causes the issue -- a stale WRONLY lock have appeared.


Simplified test case (using smbclient):

Samba-3.4 (3.5 is affected as well), "dos filemode = yes"

Consider a directory:

drwxrwxr-x 2 root group 4096 Dec 27 21:12 directory


two files in it:

-rw-rw-r-- 1 user group  8358 Dec 27 20:50 test0

-rw-rw-r-- 1 root group  8358 Dec 27 20:40 test1

and a user "user", who is a member of a group "group".

In other words, user owns "test0" and has write access (by group perms) 
to the "test1". According to the "dos filemode = yes" the user should be 
capable to change access bits for both files (not "test0" only).


Run:

smbclient //SERVER/SHARE -U user%password

and try to use "setmode testX +r".

After the "setmode test0 +r" the correspond bits are changed, 
"smbstatus" at the "SERVER" shows no lock. (You can revert by "setmode 
test0 -r" and so on as the owner of the file).

After the "setmode test1 +r", the correspond bits are changed as well, 
because the "user" has write acess to this file and "dos filemode = yes" 
is set. BUT after this operation, the smbstatus on the SERVER shows a 
stale lock:

<pid> <uid>       DENY_NONE  0x82        WRONLY     NONE             
/server/share   directory/test1   Tue Dec 28 18:02:12 2010


Certainly, in this simplified test the stale lock disappears after you 
exit the smbclient utility. But anyway it shows that something going 
wrong. The initial case in my production environment (samba servers and 
windows clients) is slightly different -- it seems that the windows 
machine first lock for "change attributes", then another lock for 
"write" (by open_file_fchmod), then the user cannot reopen the file 
until reboot or relogin to the server.

I can perform any further tests etc.


Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy