Bug 7892 - open_file_fchmod() leaves a stale lock.
Summary: open_file_fchmod() leaves a stale lock.
Alias: None
Product: Samba 3.4
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
: 7631 (view as bug list)
Depends on:
Reported: 2010-12-28 15:01 UTC by Jeremy Allison
Modified: 2010-12-31 12:59 UTC (History)
2 users (show)

See Also:

git-am patch for 3.5.next (5.42 KB, patch)
2010-12-28 19:26 UTC, Jeremy Allison
vl: review+
git-am patch for 3.4.next (5.58 KB, patch)
2010-12-28 20:13 UTC, Jeremy Allison
vl: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2010-12-28 15:01:47 UTC
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

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.
Comment 1 Jeremy Allison 2010-12-28 15:02:25 UTC
Additional followup from Dmitry Butskoy <buc@odusz.so-cdu.ru>

Well, the correspond git change is:

When I revert it (for samba 3.4.9) the problem disappears (no any
locks pending).
Comment 2 Jeremy Allison 2010-12-28 19:26:59 UTC
Created attachment 6175 [details]
git-am patch for 3.5.next
Comment 3 Jeremy Allison 2010-12-28 20:13:06 UTC
Created attachment 6176 [details]
git-am patch for 3.4.next
Comment 4 Volker Lendecke 2010-12-29 01:17:57 UTC
Comment on attachment 6176 [details]
git-am patch for 3.4.next

Haven't tested it, but it looks right.

Comment 5 Dmitry Butskoy 2010-12-29 08:27:38 UTC
The patch fixes the issue for me (samba-3.4.9), both the simplified test and the actual case in production environment are OK now.
Comment 6 Dmitry Butskoy 2010-12-29 09:19:16 UTC
Bug #7631 looks like the same issue.
Comment 7 Jeremy Allison 2010-12-29 16:03:59 UTC
*** Bug 7631 has been marked as a duplicate of this bug. ***
Comment 8 Karolin Seeger 2010-12-31 12:59:57 UTC
Pushed to v3-5-test and v3-4-test.
Will be included in the next releases.
Closing out bug report.