Numeric group IDs for system groups

Numeric group IDs for system groups

[Stefan Baur]

Hi List,

I am the community manager of X2Go, an open-source remote desktop and
remote application solution for Linux servers.  While our server
component only runs on Linux, our client software is available for macOS
and Windows as well.  The Windows version of X2GoClient relies on some
executables available through Cygwin.

On Windows 10, we are encountering the issue mentioned here in the FAQ:
<https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working>

Especially, we're getting hit by the fact that Microsoft has changed the
default group for %USERPROFILE% (and all files and directories created
in it) from "None" to <Username>.

This is why the second-to-last suggestion in that FAQ item doesn't help:

chgrp `id -g` ~/.ssh/*

will simply set the default group to the value it already has, and that
doesn't fix the issue.

The last suggestion in that FAQ item suggests using

chgrp None ~/.ssh/*

but also notes that the group name will vary depending on the operating
system language.

chgrp does work with numeric group identifiers, and it seems the "None"
group always gets the numeric id 197121 - so

chgrp 197121 ~/.ssh/*

would fix the issue regardless of the operating system language.

(In our case, it would be

chgrp 197121 %USERPROFILE%/.x2go/etc/ssh_host_key*

because it actually affects the host keys of an sshd running on the
Windows side, which we need for file sharing via sshfs, but you get the
idea.)

Can anyone with authority on the issue confirm that 197121 always
corresponds to the "None" group (whatever it may be called due to the
language setting - in German, it is "Kein", for example)?

Or is this a faulty assumption and merely coincidence that we got that
result on the handful of machines we used for testing?

I'm seriously hoping this id is always the same, similar to the
well-known SIDs in Windows, but would really like a confirmation from
someone knowledgeable before we make the corresponding change in our
code and hose a large percentage of our users' systems once they deploy
the update.

In case it is of relevance, we are calling the executables (ssh-keygen,
sshd, and now chgrp and possibly setfacl as well) directly from a native
Windows application written in Qt and C++, not from a Cygwin bash window
or similar.  In fact, there is no cygwin installation, it's just the
required executables and dlls residing in our own installation
directory.  I can provide more detail or get you in contact with one of
our developers, if needed.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Numeric group IDs for system groups

[Brian Inglis]

On 2018-05-23 13:44, Stefan Baur wrote:
> I am the community manager of X2Go, an open-source remote desktop and
> remote application solution for Linux servers.  While our server
> component only runs on Linux, our client software is available for macOS
> and Windows as well.  The Windows version of X2GoClient relies on some
> executables available through Cygwin.
> On Windows 10, we are encountering the issue mentioned here in the FAQ:
> <https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working>
> Especially, we're getting hit by the fact that Microsoft has changed the
> default group for %USERPROFILE% (and all files and directories created
> in it) from "None" to <Username>.
> This is why the second-to-last suggestion in that FAQ item doesn't help:
> chgrp `id -g` ~/.ssh/*
> will simply set the default group to the value it already has, and that
> doesn't fix the issue.
> The last suggestion in that FAQ item suggests using
> chgrp None ~/.ssh/*
> but also notes that the group name will vary depending on the operating
> system language.
> chgrp does work with numeric group identifiers, and it seems the "None"
> group always gets the numeric id 197121 - so
> chgrp 197121 ~/.ssh/*
> would fix the issue regardless of the operating system language.
> (In our case, it would be
> chgrp 197121 %USERPROFILE%/.x2go/etc/ssh_host_key*
> because it actually affects the host keys of an sshd running on the
> Windows side, which we need for file sharing via sshfs, but you get the
> idea.)
> Can anyone with authority on the issue confirm that 197121 always
> corresponds to the "None" group (whatever it may be called due to the
> language setting - in German, it is "Kein", for example)?
> Or is this a faulty assumption and merely coincidence that we got that
> result on the handful of machines we used for testing?
> I'm seriously hoping this id is always the same, similar to the
> well-known SIDs in Windows, but would really like a confirmation from
> someone knowledgeable before we make the corresponding change in our
> code and hose a large percentage of our users' systems once they deploy
> the update.
> In case it is of relevance, we are calling the executables (ssh-keygen,
> sshd, and now chgrp and possibly setfacl as well) directly from a native
> Windows application written in Qt and C++, not from a Cygwin bash window
> or similar.  In fact, there is no cygwin installation, it's just the
> required executables and dlls residing in our own installation
> directory.  I can provide more detail or get you in contact with one of
> our developers, if needed.

Cygwin id 197121 == RID 513 == 0x201 - in range of reserved RIDs < 1000.
See:
	https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-how
	https://msdn.microsoft.com/en-us/library/aa379649.aspx
	https://en.wikipedia.org/wiki/Security_Identifier

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Numeric group IDs for system groups

[Stefan Baur]

Am 23.05.2018 um 23:33 schrieb Brian Inglis:
> Cygwin id 197121 == RID 513 == 0x201 - in range of reserved RIDs < 1000.
> See:
> 	https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-how
> 	https://msdn.microsoft.com/en-us/library/aa379649.aspx
> 	https://en.wikipedia.org/wiki/Security_Identifier

So we can safely assume that 197121 will always be the "None" group?
In that case, I would suggest updating the FAQ to use

chgrp 197121 ~/.ssh/*

instead of

chgrp None ~/.ssh/*

thus making the FAQ entry
<https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working>
os-language independent.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Numeric group IDs for system groups

[Brian Inglis]

On 2018-05-23 15:47, Stefan Baur wrote:
> Am 23.05.2018 um 23:33 schrieb Brian Inglis:
>> Cygwin id 197121 == RID 513 == 0x201 - in range of reserved RIDs < 1000.
>> See:
>> 	https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-how
>> 	https://msdn.microsoft.com/en-us/library/aa379649.aspx
>> 	https://en.wikipedia.org/wiki/Security_Identifier
> So we can safely assume that 197121 will always be the "None" group?
> In that case, I would suggest updating the FAQ to use
> chgrp 197121 ~/.ssh/*
> instead of
> chgrp None ~/.ssh/*
> thus making the FAQ entry
> <https://cygwin.com/faq/faq.html#faq.using.ssh-pubkey-stops-working>
> os-language independent.

That internal id mapping could change due to Windows changes.

Currently the FAQ is only available in English - we would be grateful for
volunteers to translate to other languages. ;^>

If you are using or distributing a system or package using Cygwin components,
please provide an automated means, and a documented manual process, for applying
updates, to avoid emails from your users to this list when there is an issue due
to Windows updates.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple