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

[Ramsay Jones <ramsay@ramsayjones.plus.com>]

On 05/11/2021 11:47, Adam Dinwoodie wrote:
> On Thursday 04 November 2021 at 08:09 pm +0000, Ramsay Jones wrote:
>> 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)

Just FYI, tests t4202, t5534 and t6200 all pass for me without issue
on both of the -rc0 and -rc1 builds.

> 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.

Heh, yeah, given the setup above, I'm not exactly shocked that you
are running into permission problems ... ;-)

> ```
> # 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 have been using cygwin since the 'beta-8' days (windows NT 3.51, so about
1997 or so) and have run into several permission problems over the years.
So, in order to finesse these issues, I find it best to keep it simple.
I do not move outside of my cygwin installation (at C:\cygwin64), which
even includes my home directory and all git repos.

So, for me:
  
  $ echo $HOME
  /home/ramsay
  $ cygpath -w /home/ramsay
  C:\cygwin64\home\ramsay
  $ 
  
  $ getfacl /cygdrive/c/cygwin64
  # file: /cygdrive/c/cygwin64
  # owner: ramsay
  # group: None
  user::rwx
  group::r-x
  other::r-x
  default:user::rwx
  default:group::r-x
  default:other::r-x
  
  $ id
  uid=1001(ramsay) gid=513(None) groups=513(None),545(Users),4(INTERACTIVE),66049(CONSOLE LOGON),11(Authenticated Users),15(This Organization),113(Local account),4095(CurrentSession),66048(LOCAL),262154(NTLM Authentication),401408(Medium Mandatory Level)
  $

> 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!

I'm definitely no expert, but even with my current setup, I have had
permission problems. I used to 'ssh' into cygwin from Linux so that
I could build/test git on Linux/cygwin at the same time - that worked
fine for many many years, until a test was added that failed when I
was remotely logged-in to cygwin, but passed when I was actually directly
logged-in on the windows laptop. I don't remember the details, but ever
since I have been having to run the tests locally.

[When remotely logged in:

  $ id
  uid=1001(ramsay) gid=513(None) groups=513(None),114(Local account and member of Administrators group),0(root),545(Users),2(NETWORK),11(Authenticated Users),15(This Organization),113(Local account),4095(CurrentSession),262154(NTLM Authentication),405504(High Mandatory Level)
  $ 

Yes, I am still using the 'privileged user' account for the 'sshd' service.
I suppose I should re-configure it to use the LOCAL ACCOUNT and test again,
but, well, if it ain't broke ... ;-)
]

ATB,
Ramsay Jones