Dmitry Butskoy <buc@odusz.so-cdu.ru> reports:

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.