dos filemode: a stale lock since 3.4
buc at odusz.so-cdu.ru
Tue Dec 28 08:20:42 MST 2010
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).
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
<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.
More information about the samba-technical