dos filemode: a stale lock since 3.4
Dmitry Butskoy
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:
http://git.samba.org/?p=samba.git;a=commitdiff;h=6f7f4b428a86921e9532c62856873a19202f286d
When I revert it (for samba 3.4.9) the problem disappears (no any locks
pending).
Any comments? Is this a correct fix?
Regards
Dmitry Butskoy
>
>
> 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.
>
More information about the samba-technical
mailing list