On 05/11/2021 11:47, Adam Dinwoodie wrote:

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

quoted

Hi Adam,

On 04/11/2021 19:25, Adam Dinwoodie wrote:

quoted

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