dos filemode: a stale lock since 3.4

[Dmitry Butskoy]

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.
>