dos filemode: a stale lock since 3.4
buc at odusz.so-cdu.ru
Tue Dec 28 09:17:42 MST 2010
Dmitry Butskoy wrote:
> 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.
Well, the correspond git change is:
When I revert it (for samba 3.4.9) the problem disappears (no any locks
Any comments? Is this a correct fix?
> 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"
> 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.
More information about the samba-technical