Re: No fchmod() under msygit - Was: Re: [PATCH 00/14] Add submodule test harness

From: Nico Williams <nico@cryptonector.com>
Date: Jul 14, 2014, 13:55 UTC
Message-ID: <CAK3OfOjoqOsL5GnJAC251gqRoQo_4qwKMicLSod=7ZA69SL68w@mail.gmail.com>
In-Reply-To: <CABPQNSY5x_JOsxyKn7xZ9nc5TJ0yHdNvam0htyX01U58bvV7vg@mail.gmail.com>

On Mon, Jul 14, 2014 at 6:31 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:

Show 8 quoted lines

> On Wed, Jul 9, 2014 at 10:00 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> Torsten Bögershausen <tboegi@web.de> wrote:
>>
>
> You're saying this as if Windows is a single-user system. It's not,
> but it uses ACLs rather than POSIX permissions to manage file-system
> permissions. So far we've opted to ignore ACLs in Git for Windows,
> though.

The clever thing to do (that some versions of ZFS do nowadays) is to use the new mask to "edit" the ACL as follows:

 - leave any DENY ACEs as-is; for all others continue

 - remove (reset) from any ACEs for Everyone (and/or Authenticated
Users) any bits corresponding to zero'ed bits in the new mask's other
bits

 - remove from any other ACEs that are not for the owner (@OWNER in
NFSv4 speak) any bits corresponding to zero'ed bits in the new mask's
group bits

 - remove from the owner's ACEs any bits corresponding to zero'ed bits
in the new mask's owner bits, but with some exceptions, in particular
the owner must retain the right to edit the ACL

 - add (set) to the Everyone (and/or Authenticated Users) ACEs a set
of bits corresponding to the set bits in the new mask's other bits

 - add (set) either only to the ACE for the file's group
(alternatively, to all non-owner, non-Everyone/Authenticated Users
ACEs) a set of bits corresponding to the set bits in the new mask's
group bits

...

I.e., use the chmod mask to decrease/increase access without changing the "shape" of the ACL.

Determining a file's mode_t from an ACL is similar, though it must take DENY entries into account: make a set of users/groups referred to by any ACEs in the ACL, divide them into owner, other (Everyone and/or Authenticated Users), and group (all others), find the maximal access granted.

Still, git might like to know what ACLs to apply to files at checkout time. That would be a vast new feature, I think, and probably not worth it, particularly since that would require dealing with the different types of ACLs: NTFS/NFSv4/ZFS on the one hand, POSIX Draft on the other, plus AFS and who knows what else -- ETOOMUCH IMO.

Nico --