Re: [PATCH] t/lib-git.sh: fix ACL-related permissions failure

From: Adam Dinwoodie <adam@dinwoodie.org>
Date: Nov 5, 2021, 11:47 UTC
Message-ID: <20211105114747.GB25887@dinwoodie.org>
In-Reply-To: <6acb22bc-a90c-b8b6-2e7d-d7e17ba595ea@ramsayjones.plus.com>

On Thursday 04 November 2021 at 08:09 pm +0000, Ramsay Jones wrote:

Show 15 quoted lines

> Hi Adam,
> 
> On 04/11/2021 19:25, Adam Dinwoodie wrote:
> > SSH keys are expected to be created with very restrictive permissions,
> > and SSH commands will fail if the permissions are not appropriate.  When
> > creating a directory for SSH keys in test scripts, attempt to clear any
> > ACLs that might otherwise cause the private key to inherit less
> > restrictive permissions than it requires.
> 
> I was somewhat surprised to see your report, since all these tests
> passed without issue for me on '-rc0'! :D (64-bit cygwin only).
> 
> So, the difference seems to be down to FS ACLs, Hmmm ...
> 
> (BTW, I am on windows 10 21H1)

I'm running these tests in subdirectories in the temporary drive on Dv4-size Windows 11 Pro Gen2 Azure VMs. I'm spinning up fresh VMs and using new Cygwin installations regularly, in the name of build reproducibility; I'm vaguely working on automating more and more of the Cygwin Git test and release processes.

(At some point now they're becoming available, I'll probably shift to Ddv5 Azure VMs for this work; I very much doubt that'll make a difference, but I note it for the sake of completeness. Longer-term, I'm hoping to swap to using GitHub Actions to do most of the heavy lifting.)

This isn't the first time I've seen similar problems in this environment that haven't been spotted elsewhere: see a1e03535db (t4129: fix setfacl-related permissions failure, 2020-12-23).

The `getfacl` output for the temporary drive, from Cygwin's perspective, is as below; I'm `cd`ing into that directory and getting the Git repositories by running `git clone https://github.com/git/git` from there.

``` # file: /cygdrive/d # owner: NETWORK SERVICE # group: NETWORK SERVICE user::r-x group::r-x group:SYSTEM:rwx #effective:r-x group:Administrators:rwx #effective:r-x group:Users:r-x mask::r-x other::r-x default:user::rwx default:group::--- default:group:SYSTEM:rwx default:group:Administrators:rwx default:group:Users:rwx default:mask::rwx default:other::r-x ```

I'm honestly not sure what it is that means I keep hitting these problems with this setup. I've managed to avoid needing anything but the most cursory knowledge of extended permissions handling, particularly for Cygwin where one has to contend with both the underlying OS's interpretation of file permissions and with the Cygwin layer's reinterpretations. I can't say I'm keen to get a deep working knowledge of how all these pieces interact!