Bug 6920 - Changing owner of a file works only once without resetting the ACL
Changing owner of a file works only once without resetting the ACL
Product: Samba 3.4
Classification: Unclassified
Component: File services
Other Windows XP
: P3 normal
: ---
Assigned To: Volker Lendecke
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2009-11-23 15:47 UTC by Barry Sabsevitz
Modified: 2009-11-25 16:38 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Barry Sabsevitz 2009-11-23 15:47:06 UTC
When I change ownership using a "take ownership" operation on a file using windows explorer, the change of the ownership works fine. If I then try to change the ownership again, it fails with access denied. To reproduce:

1. Create a file as user 1.
2. Using acl_xattr module, set an ACL on the file to allow user 2 full access rights.
3. Login as user 2 and change the ownership of the file from user1 to user 2. This will work properly.
4. Login as user 1 and change the ownership of the file from user2 back to user 1. This will fail with access denied.

The NT acls look fine. I think the issue is with the POSIX ACLs. I think what is happening is that when the ownership of the file is changed from user 1 to user 2, though the Windows ACL for user 1 still exists, the POSIX ACL for user 1 has been removed. So the attempt to change the ownership a subsequent time fails. I believe this is an issue with POSIX ACLs.

If you inserted a step above as step 3A where you clicked on the file and reset the ACL for user 1 (modify the ACL in any way), then step 4 will work properly. I presume this is because the POSIX ACL for user 1 was put back on the file.
Comment 1 Jeremy Allison 2009-11-25 16:38:54 UTC
Ok, I think this is another facet of bug #6878, which I've already fixed in master and 3.5.0.


Check out the patch that went into master and 3.5.0 (this is an attachment to that bug). It fixes the lossy mapping for CREATOR_OWNER in the POSIX ACL mapping.

With this fix in master I can't reproduce this problem in this branch.