Re: Test failure for v2.16.0-rc0 on cygwin

From: Ramsay Jones <ramsay@ramsayjones.plus.com>
Date: Jan 10, 2018, 23:17 UTC
Message-ID: <87f53af7-4f5b-22a7-b950-772eb67b0151@ramsayjones.plus.com>
In-Reply-To: <alpine.DEB.2.21.1.1801042152570.32@MININT-6BKU6QN.europe.corp.microsoft.com>

On 04/01/18 20:55, Johannes Schindelin wrote:

> On Tue, 2 Jan 2018, Ramsay Jones wrote:

[snip]

Show 10 quoted lines

>> Also, when logged-in remotely it fails consistently, when logged-in
>> directly it passes consistently. :-D
> 
> You are most likely hitting cmd.exe at some point there. In cmd.exe, there
> are some restrictions that are inherited by spawned processes AFAIU. For
> example, the current directory cannot be a UNC path.
> 
> You are most likely running the interactive Cygwin session in MinTTY? Then
> you do not get those restrictions. If you start Cygwin in a cmd.exe
> window, you should see the exact same test failures again.

I actually don't see a difference when starting cygwin from a cmd.exe, it passes just fine. The interactive cygwin session(s), either directly, or most often via the X-server (with ssh-agent in between!), all have their id's and group membership look like:

  $ who
  $ 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),66048(LOCAL),262154(NTLM Authentication),401408(Medium Mandatory Level)
  $

However, when remotely logged-in over shh, it looks like:

  $ who -H
  NAME     LINE         TIME             COMMENT
  ramsay   pty2         2018-01-02 19:48 (192.168.1.2)
  $ id
  uid=1001(ramsay) gid=513(None) groups=513(None),11(Authenticated Users),66048(LOCAL),66049(CONSOLE LOGON),4(INTERACTIVE),15(This Organization),545(Users),0(root),405504(High Mandatory Level)
  $

So, when remotely logged-in, we have:

  Additional groups: 0(root), 405504(High Mandatory Level)

  Missing groups: 113(Local account), 262154(NTLM Authentication),
                  401408(Medium Mandatory Level)

I haven't thought too much about what that means ...

After reading this[1], I have been meaning to try setting the 'LocalAccountTokenFilterPolicy' registry variable mentioned in that article, to see if that would make any difference. I haven't found the time yet ... :-D

ATB, Ramsay Jones

[1] http://www.tomsitpro.com/articles/windows-10-administrative-shares,2-47.html