Patch from Michael Steffens. In his own words :

-------------------------------------------------------------------------
I think there are basically two problem:

  1. Windows clients do not always send ACEs for SMB_ACL_USER_OBJ, SMB_ACL_GROUP_OBJ,
     and SMB_ACL_OTHER.
     The function ensure_canon_entry_valid() is prepared for that, but tries
     to "guess" values from group or other permissions, respectively, otherwise
     falling back to minimum r-- for the owner. Even if the owner had full
     permissions before setting ACL. This is the problem with W2k clients.

  2. Function set_nt_acl() always chowns *before* attempting to set POSIX ACLs.
     This is ok in a take-ownership situation, but must fail if the file is
     to be given away. This is the problem with XP clients, trying to transfer
     ownership of the original file to the temp file.

The problem with NT4 clients (no ACEs are transferred to the temp file, thus
are lost after moving the temp file to the original name) is a client problem.
It simply doesn't attempt to.

I have played around with that using posic_acls.c from 3.0 merged into 2.2.
As a result I can now present two patches, one for each branch. They
basically modify:

  1. Interpret missing SMB_ACL_USER_OBJ, SMB_ACL_GROUP_OBJ, or SMB_ACL_OTHER
     as "preserve current value" instead of attempting to build one ourself.
     The original code is still in, but only as fallback in case current values
     can't be retrieved.

  2. Rearrange set_nt_acl() such that chown is only done before setting
     ACLs if there is either no change of owning user, or change of owning
     user is towards the current user. Otherwise chown is done after setting
     ACLs.

It now seems to produce reasonable results. (Well, as far as it can. If
NT4 doesn't even try to transfer ACEs, only deliberate use of named default
ACEs and/or "force group" or the crystal ball can help :)
-------------------------------------------------------------------------
Jeremy.
(This used to be commit 8ec20cbae7ca7e685b1a4186d8482c7405915dc3)

0 files changed, 0 insertions, 0 deletions