Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Roland Mainz]

Hi!

----

If I switch the current user's group with /usr/bin/newgrp, how can a
(native) Win32 process use
|GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
group is the new "current group" (e.g. which |TokenInformationClass|
should I use) ?

----

Bye,
Roland Mainz
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> Hi!
> 
> ----
> 
> If I switch the current user's group with /usr/bin/newgrp, how can a
> (native) Win32 process use
> |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> group is the new "current group" (e.g. which |TokenInformationClass|
> should I use) ?

  PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
  NTSTATUS status;
  ULONG size;

  status = NtQueryInformationToken (hProcToken, TokenPrimaryGroup,
                                    sidbuf, SECURITY_MAX_SID_SIZE,
				    &size);


Corinna

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Roland Mainz]

On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
> On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > If I switch the current user's group with /usr/bin/newgrp, how can a
> > (native) Win32 process use
> > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > group is the new "current group" (e.g. which |TokenInformationClass|
> > should I use) ?
>
>   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
>   NTSTATUS status;
>   ULONG size;
>
>   status = NtQueryInformationToken (hProcToken, TokenPrimaryGroup,
>                                     sidbuf, SECURITY_MAX_SID_SIZE,
>                                     &size);

Well, it works in the case of an "hello world" application, but if I
stuff that into the nfsd_daemon (NFSv4.1 ms-nfs41-client client
daemon) it always prints the default primary group, even if the
current thread should impersonate another user - or in this case even
the same user, but a different primary group (e.g. see
https://github.com/kofemann/ms-nfs41-client/blob/master/sys/nfs41_driver.c#L1367).

Do you have any idea what is going wrong in this case ?

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Feb 23 14:03, Roland Mainz via Cygwin wrote:
> On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > (native) Win32 process use
> > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > should I use) ?
> >
> >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> >   NTSTATUS status;
> >   ULONG size;
> >
> >   status = NtQueryInformationToken (hProcToken, TokenPrimaryGroup,
> >                                     sidbuf, SECURITY_MAX_SID_SIZE,
> >                                     &size);
> 
> Well, it works in the case of an "hello world" application, but if I
> stuff that into the nfsd_daemon (NFSv4.1 ms-nfs41-client client
> daemon) it always prints the default primary group, even if the
> current thread should impersonate another user - or in this case even
> the same user, but a different primary group (e.g. see
> https://github.com/kofemann/ms-nfs41-client/blob/master/sys/nfs41_driver.c#L1367).
> 
> Do you have any idea what is going wrong in this case ?

Not sure about that.  I'm not familiar with driver development under
Windows.  I'd expect that you get the token of the calling thread or, in
this case, process as is.

However, did you try this with a primary group SID being part of the
token's supplementary group list, or did you try this with some
arbitrary group SID?

I toyed around a bit with this in user space, and it seems I
misinterpreted the results when I added the newgrp(1) tool.  The primary
group in the token *must* be member of the token's supplementary group
list.

The fact that it looks like it works in Cygwin to set the pgrp to
an arbitrary SID is apparently based on incorrect error handling.

I will fix this in the next couple of days.


Corinna

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Roland Mainz]

On Fri, Feb 23, 2024 at 4:47 PM Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
> On Feb 23 14:03, Roland Mainz via Cygwin wrote:
> > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > > (native) Win32 process use
> > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > should I use) ?
> > >
> > >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > >   NTSTATUS status;
> > >   ULONG size;
> > >
> > >   status = NtQueryInformationToken (hProcToken, TokenPrimaryGroup,
> > >                                     sidbuf, SECURITY_MAX_SID_SIZE,
> > >                                     &size);
> >
> > Well, it works in the case of an "hello world" application, but if I
> > stuff that into the nfsd_daemon (NFSv4.1 ms-nfs41-client client
> > daemon) it always prints the default primary group, even if the
> > current thread should impersonate another user - or in this case even
> > the same user, but a different primary group (e.g. see
> > https://github.com/kofemann/ms-nfs41-client/blob/master/sys/nfs41_driver.c#L1367).
> >
> > Do you have any idea what is going wrong in this case ?
>
> Not sure about that.  I'm not familiar with driver development under
> Windows.

Me neither, I'm still new to this whole Windows kernel stuff (coming
from SUN&Solaris engineering), but as we need a NFSv4 filesystem
client at work I'm basically forced at knifepoint to learn as fast as
I can... ;-/

> I'd expect that you get the token of the calling thread or, in
> this case, process as is.

I think it's the calling thread which makes the Win32 syscall, then
the MiniRedirector driver (nfs41_driver.sys) gets that security
context, and uses that to set the impersonation stuff when making the
upcall to the userland part (nfsd_debug.exe), so that daemon thread
can impersonate the caller.

> However, did you try this with a primary group SID being part of the
> token's supplementary group list, or did you try this with some
> arbitrary group SID?

I tried it like this:
1. On the Windows machine I created these two new groups:
---- snip ----
WINHOST1:~$ net localgroup cygwingrp1 /add
WINHOST1:~$ net localgroup cygwingrp2 /add
WINHOST1:~$ getent group cygwingrp1
cygwingrp1:S-1-5-21-3286904461-661230000-4220857270-1003:197611:
WINHOST1:~$ getent group cygwingrp2
cygwingrp2:S-1-5-21-3286904461-661230000-4220857270-1004:197612:
---- snip ----

On the Linux NFSv4 server side I added these groups too, and added
group membership for the matching user:
---- snip ----
root@DERFWNB4966:~# groupadd -g 197611 cygwingrp1
root@DERFWNB4966:~# groupadd -g 197612 cygwingrp2
root@DERFWNB4966:~# usermod -a -G cygwingrp1 roland_mainz
root@DERFWNB4966:~# usermod -a -G cygwingrp2 roland_mainz
---- snip ----

After that /usr/bin/chgrp on Cygwin works on the NFSv4.1 filesystem,
but if I do a /usr/bin/newgrp+/usr/bin/touch it will not create files
with that new group, because nfsd_debug.exe only sees the default
primary group, not the new primary group set by /usr/bin/newgrp.

Or is there a mistake - do I have to add the current user to the
Windows localgroup first somehow (like usermod on Linux) ?

> I toyed around a bit with this in user space, and it seems I
> misinterpreted the results when I added the newgrp(1) tool.  The primary
> group in the token *must* be member of the token's supplementary group
> list.

Like on UNIX, right ?

> The fact that it looks like it works in Cygwin to set the pgrp to
> an arbitrary SID is apparently based on incorrect error handling.
>
> I will fix this in the next couple of days.

Thanks :-)

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Dan Shelton]

On Fri, 23 Feb 2024 at 19:45, Roland Mainz via Cygwin <cygwin@cygwin.com> wrote:
>
> On Fri, Feb 23, 2024 at 4:47 PM Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> > On Feb 23 14:03, Roland Mainz via Cygwin wrote:
> > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> > > <cygwin@cygwin.com> wrote:
> > > > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > > > (native) Win32 process use
> > > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > > should I use) ?
> > > >
> > > >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > > >   NTSTATUS status;
> > > >   ULONG size;
> > > >
> > > >   status = NtQueryInformationToken (hProcToken, TokenPrimaryGroup,
> > > >                                     sidbuf, SECURITY_MAX_SID_SIZE,
> > > >                                     &size);
> > >
> > > Well, it works in the case of an "hello world" application, but if I
> > > stuff that into the nfsd_daemon (NFSv4.1 ms-nfs41-client client
> > > daemon) it always prints the default primary group, even if the
> > > current thread should impersonate another user - or in this case even
> > > the same user, but a different primary group (e.g. see
> > > https://github.com/kofemann/ms-nfs41-client/blob/master/sys/nfs41_driver.c#L1367).
> > >
> > > Do you have any idea what is going wrong in this case ?
> >
> > Not sure about that.  I'm not familiar with driver development under
> > Windows.
>
> Me neither, I'm still new to this whole Windows kernel stuff (coming
> from SUN&Solaris engineering), but as we need a NFSv4 filesystem
> client at work I'm basically forced at knifepoint to learn as fast as
> I can... ;-/
>
> > I'd expect that you get the token of the calling thread or, in
> > this case, process as is.
>
> I think it's the calling thread which makes the Win32 syscall, then
> the MiniRedirector driver (nfs41_driver.sys) gets that security
> context, and uses that to set the impersonation stuff when making the
> upcall to the userland part (nfsd_debug.exe), so that daemon thread
> can impersonate the caller.
>
> > However, did you try this with a primary group SID being part of the
> > token's supplementary group list, or did you try this with some
> > arbitrary group SID?
>
> I tried it like this:
> 1. On the Windows machine I created these two new groups:
> ---- snip ----
> WINHOST1:~$ net localgroup cygwingrp1 /add
> WINHOST1:~$ net localgroup cygwingrp2 /add
> WINHOST1:~$ getent group cygwingrp1
> cygwingrp1:S-1-5-21-3286904461-661230000-4220857270-1003:197611:
> WINHOST1:~$ getent group cygwingrp2
> cygwingrp2:S-1-5-21-3286904461-661230000-4220857270-1004:197612:
> ---- snip ----
>
> On the Linux NFSv4 server side I added these groups too, and added
> group membership for the matching user:
> ---- snip ----
> root@DERFWNB4966:~# groupadd -g 197611 cygwingrp1
> root@DERFWNB4966:~# groupadd -g 197612 cygwingrp2
> root@DERFWNB4966:~# usermod -a -G cygwingrp1 roland_mainz
> root@DERFWNB4966:~# usermod -a -G cygwingrp2 roland_mainz
> ---- snip ----
>
> After that /usr/bin/chgrp on Cygwin works on the NFSv4.1 filesystem,
> but if I do a /usr/bin/newgrp+/usr/bin/touch it will not create files
> with that new group, because nfsd_debug.exe only sees the default
> primary group, not the new primary group set by /usr/bin/newgrp.
>
> Or is there a mistake - do I have to add the current user to the
> Windows localgroup first somehow (like usermod on Linux) ?

Yes, there is a mistake. You have to add the intended user to that group.

Example:
net localgroup mywingrp1 mywinuser44 /add

HOWEVER, there is another Cygwin bug:
"getent group mywingrp1" does not list any group members, even after
"net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
violation.

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Feb 23 19:45, Roland Mainz via Cygwin wrote:
> On Fri, Feb 23, 2024 at 4:47 PM Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> > On Feb 23 14:03, Roland Mainz via Cygwin wrote:
> > > Do you have any idea what is going wrong in this case ?
> >
> > Not sure about that.  I'm not familiar with driver development under
> > Windows.
> 
> Me neither, I'm still new to this whole Windows kernel stuff (coming
> from SUN&Solaris engineering), but as we need a NFSv4 filesystem
> client at work I'm basically forced at knifepoint to learn as fast as
> I can... ;-/
> 
> > I'd expect that you get the token of the calling thread or, in
> > this case, process as is.
> 
> I think it's the calling thread which makes the Win32 syscall, then
> the MiniRedirector driver (nfs41_driver.sys) gets that security
> context, and uses that to set the impersonation stuff when making the
> upcall to the userland part (nfsd_debug.exe), so that daemon thread
> can impersonate the caller.
> 
> > However, did you try this with a primary group SID being part of the
> > token's supplementary group list, or did you try this with some
> > arbitrary group SID?
> 
> I tried it like this:
> 1. On the Windows machine I created these two new groups:
> ---- snip ----
> WINHOST1:~$ net localgroup cygwingrp1 /add
> WINHOST1:~$ net localgroup cygwingrp2 /add
> WINHOST1:~$ getent group cygwingrp1
> cygwingrp1:S-1-5-21-3286904461-661230000-4220857270-1003:197611:
> WINHOST1:~$ getent group cygwingrp2
> cygwingrp2:S-1-5-21-3286904461-661230000-4220857270-1004:197612:
> ---- snip ----
> 
> On the Linux NFSv4 server side I added these groups too, and added
> group membership for the matching user:
> ---- snip ----
> root@DERFWNB4966:~# groupadd -g 197611 cygwingrp1
> root@DERFWNB4966:~# groupadd -g 197612 cygwingrp2
> root@DERFWNB4966:~# usermod -a -G cygwingrp1 roland_mainz
> root@DERFWNB4966:~# usermod -a -G cygwingrp2 roland_mainz
> ---- snip ----
> 
> After that /usr/bin/chgrp on Cygwin works on the NFSv4.1 filesystem,
> but if I do a /usr/bin/newgrp+/usr/bin/touch it will not create files
> with that new group, because nfsd_debug.exe only sees the default
> primary group, not the new primary group set by /usr/bin/newgrp.
> 
> Or is there a mistake - do I have to add the current user to the
> Windows localgroup first somehow (like usermod on Linux) ?

Yes, there's a mistake, but in some way it's not your fault.

You have to make sure that the user calling newgrp is member in the
group *and* it has to be in the current user token's TOKEN_GROUP list.

The fact that it (looks like it) works on Cygwin does not mean it
actually worked on the OS level.  See below.

> > I toyed around a bit with this in user space, and it seems I
> > misinterpreted the results when I added the newgrp(1) tool.  The primary
> > group in the token *must* be member of the token's supplementary group
> > list.
> 
> Like on UNIX, right ?

No.  On UNIX it depends if you're a privileged process with the
CAP_SETGID capability.  If so, you can set the pgrp to any arbitrary
group without being asked for credentials.  If you're non-priv'ed,
you can change to any group from the supplementary group list without
being asked for credentials, *or* you're asked for credentials (group
password).

> > The fact that it looks like it works in Cygwin to set the pgrp to
> > an arbitrary SID is apparently based on incorrect error handling.
> >
> > I will fix this in the next couple of days.
> 
> Thanks :-)

In fact I can't fix it and here's why:

Windows only allows to set the new primary group to a group which is
already in the TOKEN_GROUP list of the manipulated user token.  Even
a privileged account can't do that.  Only creating a new token from
scratch will do this.

However, there's a problem.  Consider the OpenSSH server sshd.  It
switches the user account basically like this:

  if (setgid(newgid) != 0)
    ERROR;
  if (setuid(newuid) !=0)
    ERROR;

Only after the setuid(2) call, Cygwin has full information to create the
new token for the process of the user just logging in.  So during the
setgid(2) call, Cygwin can only operate on the token of the service
account running sshd.

Now, if setgid(2) would fail if the group is not in the user token
of the current effective account, sshd would practically always fail.

So what Cygwin does is to fake success in setgid(2) even if switching
the pgrp in the token failed.  It just stores the information in its
internal user account representation.  Then, when setuid(2) gets called,
it will try to rectify this in the new user's token.

That's why setgid(2) always succeeds if the group exists.  We just don't
have a better way to implement the user account switch.

I just pushed a patch which lets newgrp(1) fail if the group is not
in the supplementary group list, but that's all I can do without
breaking OpenSSH.

So, again, what you have to do is to make sure that the account is
already in the group you're switching to.

For instance:

  $ id
  uid=1049577(corinna) gid=1049089(Domain Users) groups=1049089(Domain Users),545(Users),14(REMOTE INTERACTIVE LOGON),4(INTERACTIVE),11(Authenticated Users),15(This Organization),4095(CurrentSession),66048(LOCAL),70145(Authentication authority asserted identity),1049148(Denied RODC Password Replication Group),401408(Medium Mandatory Level)

So that works:

  $ newgrp 'INTERACTIVE' id -gn
  INTERACTIVE

But this will not work anymore with the new newgrp(1) from Cygwin 3.5.1:

  $ newgrp 'PROXY' id -gn
  newgrp: can't switch primary group to 'PROXY'

while it still (looks like it) works with newgrp(1) from Cygwin 3.5.0,
because setgid(2) is faking success.


HTH,
Corinna

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> HOWEVER, there is another Cygwin bug:
> "getent group mywingrp1" does not list any group members, even after
> "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> violation.

Not a bug.  Two problems:

- Getting members of a group can be an extremly costly operation
  in a domain or, worse, a domain forest, or even worse, if the 
  domain or domain forest is remote.

- Alonmg the same lines, getting members of a group can be extremly
  costly in big orgs with thousands of users.  Nobody want's to clutter
  up space with the list of members in the "Domain Users" group.

- Permissions to enumerate members of a group are restricted.
  By default only admins and group members are allow to enumerate
  members and this can be restricted further by domain admins.

Therefore we dropped even trying to populate gr_mem, considering
that even in its original form on Unix systems, it's used only
to add supplementary groups.  To do this right on Windows is even
more costly than blindly enumerating.

It's not a bug, it's a feature :)


Corinna

Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Roland Mainz]

On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
> On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > If I switch the current user's group with /usr/bin/newgrp, how can a
> > (native) Win32 process use
> > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > group is the new "current group" (e.g. which |TokenInformationClass|
> > should I use) ?
>
>   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
[snip]

Win32/NT API question: All known SIDs will fit into
|SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
the ms-nfs41-client code assumes that all SIDs use a variable amount
of memory, and we always have to ask the Win32/NT API about the number
of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum
limit for all Windows versions, then we could simplify the code a
lot...

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Brian Inglis]

On 2024-02-23 14:15, Dan Shelton via Cygwin wrote:
> On Fri, 23 Feb 2024 at 19:45, Roland Mainz via Cygwin wrote:
>> After that /usr/bin/chgrp on Cygwin works on the NFSv4.1 filesystem,
>> but if I do a /usr/bin/newgrp+/usr/bin/touch it will not create files
>> with that new group, because nfsd_debug.exe only sees the default
>> primary group, not the new primary group set by /usr/bin/newgrp.
>>
>> Or is there a mistake - do I have to add the current user to the
>> Windows localgroup first somehow (like usermod on Linux) ?
> 
> Yes, there is a mistake. You have to add the intended user to that group.
> 
> Example:
> net localgroup mywingrp1 mywinuser44 /add
> 
> HOWEVER, there is another Cygwin bug:
> "getent group mywingrp1" does not list any group members, even after
> "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> violation.

No POSIX violation as getent and nsswitch came from Solaris, and despite 
adoption by Linux, BSDs, and Cygwin, is not standardized as of SUSv5? draft 
202x_d4.1.

Cygwin `getent group` depends on `/etc/nsswitch.conf` settings, defaults to 
`files db`, and lists the contents of the entries in `/etc/group` and/or 
Security Account Manager SAM groups and/or Active Directory AD groups (could 
take a long while initially and is faster with cygserver caching).

See `getent(1)`.

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

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Feb 24 15:38, Roland Mainz via Cygwin wrote:
> On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > (native) Win32 process use
> > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > should I use) ?
> >
> >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> [snip]
> 
> Win32/NT API question: All known SIDs will fit into
> |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
> the ms-nfs41-client code assumes that all SIDs use a variable amount
> of memory, and we always have to ask the Win32/NT API about the number
> of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum
> limit for all Windows versions, then we could simplify the code a
> lot...

Yes.  ACLs are size restricted to 64K, though, but that shouldn't be
much of a problem usally.


Corinna

Re: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Roland Mainz]

On Sat, Feb 24, 2024 at 7:57 PM Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>
> On Feb 24 15:38, Roland Mainz via Cygwin wrote:
> > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > > (native) Win32 process use
> > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > should I use) ?
> > >
> > >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > [snip]
> >
> > Win32/NT API question: All known SIDs will fit into
> > |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
> > the ms-nfs41-client code assumes that all SIDs use a variable amount
> > of memory, and we always have to ask the Win32/NT API about the number
> > of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum
> > limit for all Windows versions, then we could simplify the code a
> > lot...
>
> Yes.  ACLs are size restricted to 64K, though, but that shouldn't be
> much of a problem usally.

Erm... why ACLs? I was asking about the memory allocation size for an SID.

Example:
Right now our code uses two calls to |LookupAccountNameA()| for the
conversion from a Windows account name to Windows SID.
The first call gets the allocation size for a SID, our code then
allocates that memory, and then does a second call to
|LookupAccountNameA()| to fill that memory with that SID.

If |SECURITY_MAX_SID_SIZE| (currently 68 bytes) is the maximum memory
size a Windows syscall can return for a SID, then the code above could
be simplified to a |sidmem =
malloc(SECURITY_MAX_SID_SIZE)|+|LookupAccountNameA(..., sidmem, ...)|.

The same could be done in many many other places, leading to a
considerable reduction of Win32 system library calls.

Question is whether the assumption about |SECURITY_MAX_SID_SIZE| is correct...

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[gs-cygwin.com]

On Sun, Feb 25, 2024 at 10:04:29PM +0100, Roland Mainz via Cygwin wrote:
> On Sat, Feb 24, 2024 at 7:57 PM Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> >
> > On Feb 24 15:38, Roland Mainz via Cygwin wrote:
> > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> > > <cygwin@cygwin.com> wrote:
> > > > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > > > (native) Win32 process use
> > > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > > should I use) ?
> > > >
> > > >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > > [snip]
> > >
> > > Win32/NT API question: All known SIDs will fit into
> > > |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
> > > the ms-nfs41-client code assumes that all SIDs use a variable amount
> > > of memory, and we always have to ask the Win32/NT API about the number
> > > of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum
> > > limit for all Windows versions, then we could simplify the code a
> > > lot...
> >
> > Yes.  ACLs are size restricted to 64K, though, but that shouldn't be
> > much of a problem usally.
> 
> Erm... why ACLs? I was asking about the memory allocation size for an SID.
> 
> Example:
> Right now our code uses two calls to |LookupAccountNameA()| for the
> conversion from a Windows account name to Windows SID.
> The first call gets the allocation size for a SID, our code then
> allocates that memory, and then does a second call to
> |LookupAccountNameA()| to fill that memory with that SID.
> 
> If |SECURITY_MAX_SID_SIZE| (currently 68 bytes) is the maximum memory
> size a Windows syscall can return for a SID, then the code above could
> be simplified to a |sidmem =
> malloc(SECURITY_MAX_SID_SIZE)|+|LookupAccountNameA(..., sidmem, ...)|.
> 
> The same could be done in many many other places, leading to a
> considerable reduction of Win32 system library calls.
> 
> Question is whether the assumption about |SECURITY_MAX_SID_SIZE| is correct...

A robust solution which also reduces syscalls does not necessarily
require a precise answer here.

I suggest writing a wrapper function which has on the stack
  CSTR sidbuf[SECURITY_MAX_SID_SIZE];
and calls LookupAccountNameA() passing sidbuf as Sid.
If it succeeds, then malloc() returned cbSid value and copy sidbuf[].
If it fails because the buffer is too small, then malloc() the returned
cbSid value and call LookupAccountNameA() again.

Doing the above will keep memory use to a minimum, and will generally
call LookupAccountNameA() once per wrapper func invocation rather than
twice.

Cheers, Glenn

Re: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[gs-cygwin.com]

On Sun, Feb 25, 2024 at 05:32:32PM -0500, Glenn Strauss via Cygwin wrote:
> On Sun, Feb 25, 2024 at 10:04:29PM +0100, Roland Mainz via Cygwin wrote:
> > On Sat, Feb 24, 2024 at 7:57 PM Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > >
> > > On Feb 24 15:38, Roland Mainz via Cygwin wrote:
> > > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> > > > <cygwin@cygwin.com> wrote:
> > > > > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > > > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > > > > (native) Win32 process use
> > > > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > > > should I use) ?
> > > > >
> > > > >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > > > [snip]
> > > >
> > > > Win32/NT API question: All known SIDs will fit into
> > > > |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
> > > > the ms-nfs41-client code assumes that all SIDs use a variable amount
> > > > of memory, and we always have to ask the Win32/NT API about the number
> > > > of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum
> > > > limit for all Windows versions, then we could simplify the code a
> > > > lot...
> > >
> > > Yes.  ACLs are size restricted to 64K, though, but that shouldn't be
> > > much of a problem usally.
> > 
> > Erm... why ACLs? I was asking about the memory allocation size for an SID.
> > 
> > Example:
> > Right now our code uses two calls to |LookupAccountNameA()| for the
> > conversion from a Windows account name to Windows SID.
> > The first call gets the allocation size for a SID, our code then
> > allocates that memory, and then does a second call to
> > |LookupAccountNameA()| to fill that memory with that SID.
> > 
> > If |SECURITY_MAX_SID_SIZE| (currently 68 bytes) is the maximum memory
> > size a Windows syscall can return for a SID, then the code above could
> > be simplified to a |sidmem =
> > malloc(SECURITY_MAX_SID_SIZE)|+|LookupAccountNameA(..., sidmem, ...)|.
> > 
> > The same could be done in many many other places, leading to a
> > considerable reduction of Win32 system library calls.
> > 
> > Question is whether the assumption about |SECURITY_MAX_SID_SIZE| is correct...
> 
> A robust solution which also reduces syscalls does not necessarily
> require a precise answer here.
> 
> I suggest writing a wrapper function which has on the stack
>   CSTR sidbuf[SECURITY_MAX_SID_SIZE];
> and calls LookupAccountNameA() passing sidbuf as Sid.
> If it succeeds, then malloc() returned cbSid value and copy sidbuf[].
> If it fails because the buffer is too small, then malloc() the returned
> cbSid value and call LookupAccountNameA() again.
> 
> Doing the above will keep memory use to a minimum, and will generally
> call LookupAccountNameA() once per wrapper func invocation rather than
> twice.
> 
> Cheers, Glenn

Commenters on stackoverflow provide data calculating the answer as
68 bytes for SID as binary [1]

[1] https://stackoverflow.com/questions/1140528/what-is-the-maximum-length-of-a-sid-in-sddl-format

Re: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Feb 25 22:04, Roland Mainz via Cygwin wrote:
> On Sat, Feb 24, 2024 at 7:57 PM Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> >
> > On Feb 24 15:38, Roland Mainz via Cygwin wrote:
> > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> > > <cygwin@cygwin.com> wrote:
> > > > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > > > (native) Win32 process use
> > > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > > should I use) ?
> > > >
> > > >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > > [snip]
> > >
> > > Win32/NT API question: All known SIDs will fit into
> > > |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
> > > the ms-nfs41-client code assumes that all SIDs use a variable amount
> > > of memory, and we always have to ask the Win32/NT API about the number
> > > of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum
> > > limit for all Windows versions, then we could simplify the code a
> > > lot...
> >
> > Yes.  ACLs are size restricted to 64K, though, but that shouldn't be
> > much of a problem usally.
> 
> Erm... why ACLs? I was asking about the memory allocation size for an SID.

I know, and I wrote "Yes".

I mentioned ACLs because ACLs consist of SIDs and if all SIDs take
SECURITY_MAX_SID_SIZE bytes... well, no worries.


Corinna

RE: [EXTERNAL] Re: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> A robust solution which also reduces syscalls does not necessarily
> require a precise answer here.
> 
> I suggest writing a wrapper function which has on the stack
>   CSTR sidbuf[SECURITY_MAX_SID_SIZE];
> and calls LookupAccountNameA() passing sidbuf as Sid.
> If it succeeds, then malloc() returned cbSid value and copy sidbuf[].
> If it fails because the buffer is too small, then malloc() the returned
> cbSid value and call LookupAccountNameA() again.
> 
> Doing the above will keep memory use to a minimum, and will generally
> call LookupAccountNameA() once per wrapper func invocation rather than
> twice.

+1 !

Anton Lavrentiev
Contractor NIH/NLM/NCBI

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Dan Shelton]

On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>
> On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> > HOWEVER, there is another Cygwin bug:
> > "getent group mywingrp1" does not list any group members, even after
> > "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> > violation.
>
> Not a bug.  Two problems:
>
> - Getting members of a group can be an extremly costly operation
>   in a domain or, worse, a domain forest, or even worse, if the
>   domain or domain forest is remote.
>
> - Alonmg the same lines, getting members of a group can be extremly
>   costly in big orgs with thousands of users.  Nobody want's to clutter
>   up space with the list of members in the "Domain Users" group.
>
> - Permissions to enumerate members of a group are restricted.
>   By default only admins and group members are allow to enumerate
>   members and this can be restricted further by domain admins.
>
> Therefore we dropped even trying to populate gr_mem, considering
> that even in its original form on Unix systems, it's used only
> to add supplementary groups.  To do this right on Windows is even
> more costly than blindly enumerating.
>
> It's not a bug, it's a feature :)

Could you add an option to getent so that the full lookup can be
requested via command line, pls? Always editing /etc/nsswitch.conf
forth and back is not a elegant solution, aside from race conditions
with other users on a system

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> >
> > On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> > > HOWEVER, there is another Cygwin bug:
> > > "getent group mywingrp1" does not list any group members, even after
> > > "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> > > violation.
> >
> > Not a bug.  Two problems:
> >
> > - Getting members of a group can be an extremly costly operation
> >   in a domain or, worse, a domain forest, or even worse, if the
> >   domain or domain forest is remote.
> >
> > - Alonmg the same lines, getting members of a group can be extremly
> >   costly in big orgs with thousands of users.  Nobody want's to clutter
> >   up space with the list of members in the "Domain Users" group.
> >
> > - Permissions to enumerate members of a group are restricted.
> >   By default only admins and group members are allow to enumerate
> >   members and this can be restricted further by domain admins.
> >
> > Therefore we dropped even trying to populate gr_mem, considering
> > that even in its original form on Unix systems, it's used only
> > to add supplementary groups.  To do this right on Windows is even
> > more costly than blindly enumerating.
> >
> > It's not a bug, it's a feature :)
> 
> Could you add an option to getent so that the full lookup can be
> requested via command line, pls?

That's not possible.  getent just calls getpwent/getgrent.

> Always editing /etc/nsswitch.conf
> forth and back is not a elegant solution, aside from race conditions
> with other users on a system

So, here we go again.

- What exactly are you trying to accomplish by enumerating the accounts?
  Maybe you won't actually need it for your task at hand.

- Why do you have to change nsswitch.conf "back and forth"?
  Just change it once and you're done.


Corinna

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Glenn Strauss]

On Wed, Mar 06, 2024 at 02:01:06PM +0100, Corinna Vinschen via Cygwin wrote:
> On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> > On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > >
> > > On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> > > > HOWEVER, there is another Cygwin bug:
> > > > "getent group mywingrp1" does not list any group members, even after
> > > > "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> > > > violation.
> > >
> > > Not a bug.  Two problems:
> > >
> > > - Getting members of a group can be an extremly costly operation
> > >   in a domain or, worse, a domain forest, or even worse, if the
> > >   domain or domain forest is remote.
> > >
> > > - Alonmg the same lines, getting members of a group can be extremly
> > >   costly in big orgs with thousands of users.  Nobody want's to clutter
> > >   up space with the list of members in the "Domain Users" group.
> > >
> > > - Permissions to enumerate members of a group are restricted.
> > >   By default only admins and group members are allow to enumerate
> > >   members and this can be restricted further by domain admins.
> > >
> > > Therefore we dropped even trying to populate gr_mem, considering
> > > that even in its original form on Unix systems, it's used only
> > > to add supplementary groups.  To do this right on Windows is even
> > > more costly than blindly enumerating.
> > >
> > > It's not a bug, it's a feature :)
> > 
> > Could you add an option to getent so that the full lookup can be
> > requested via command line, pls?
> 
> That's not possible.  getent just calls getpwent/getgrent.
> 
> > Always editing /etc/nsswitch.conf
> > forth and back is not a elegant solution, aside from race conditions
> > with other users on a system
> 
> So, here we go again.
> 
> - What exactly are you trying to accomplish by enumerating the accounts?
>   Maybe you won't actually need it for your task at hand.
> 
> - Why do you have to change nsswitch.conf "back and forth"?
>   Just change it once and you're done.
> 
> 
> Corinna

Hello
> > Dan Shelton - Cluster Specialist Win/Lin/Bsd

> > Always editing /etc/nsswitch.conf
> > forth and back is not a elegant solution, aside from race conditions
> > with other users on a system

Please check the man page for getent.

man getent
getent --help

You can use -s or --service to override the service used without
editing nsswitch.conf.  The man page on Linux provides an example
with a bit more details than the man page for getent under cygwin.
https://www.man7.org/linux/man-pages/man1/getent.1.html

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Dan Shelton]

On Wed, 6 Mar 2024 at 14:01, Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>
> On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> > On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > >
> > > On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> > > > HOWEVER, there is another Cygwin bug:
> > > > "getent group mywingrp1" does not list any group members, even after
> > > > "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> > > > violation.
> > >
> > > Not a bug.  Two problems:
> > >
> > > - Getting members of a group can be an extremly costly operation
> > >   in a domain or, worse, a domain forest, or even worse, if the
> > >   domain or domain forest is remote.
> > >
> > > - Alonmg the same lines, getting members of a group can be extremly
> > >   costly in big orgs with thousands of users.  Nobody want's to clutter
> > >   up space with the list of members in the "Domain Users" group.
> > >
> > > - Permissions to enumerate members of a group are restricted.
> > >   By default only admins and group members are allow to enumerate
> > >   members and this can be restricted further by domain admins.
> > >
> > > Therefore we dropped even trying to populate gr_mem, considering
> > > that even in its original form on Unix systems, it's used only
> > > to add supplementary groups.  To do this right on Windows is even
> > > more costly than blindly enumerating.
> > >
> > > It's not a bug, it's a feature :)
> >
> > Could you add an option to getent so that the full lookup can be
> > requested via command line, pls?
>
> That's not possible.  getent just calls getpwent/getgrent.

What about environment variables? NSSWITCH_PATH=/etc/nsswitch.conf
would be the default, and then let scripts customise it

>
> > Always editing /etc/nsswitch.conf
> > forth and back is not a elegant solution, aside from race conditions
> > with other users on a system
>
> So, here we go again.
>
> - What exactly are you trying to accomplish by enumerating the accounts?
>   Maybe you won't actually need it for your task at hand.

We're trying to do several things, including but not limited to:
- Finding which local groups exist. Part of our customer software
expects that certain groups exist. Unfortunately the group names vary
between installations, and sometimes names are prefixed with site
names. Trying to do all permutations with just getent passwd
$iteration means too many combinations (>= 4000000). So just
enumerating all local groups with getent group would be the way to go.
- get the uid and gid used by Cygwin, so the scripts can use  them
later for tar/pax and other scripts

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Dan Shelton]

On Sat, 9 Mar 2024 at 22:27, Glenn Strauss via Cygwin <cygwin@cygwin.com> wrote:
>
> On Wed, Mar 06, 2024 at 02:01:06PM +0100, Corinna Vinschen via Cygwin wrote:
> > On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> > > On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin
> > > <cygwin@cygwin.com> wrote:
> > > >
> > > > On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> > > > > HOWEVER, there is another Cygwin bug:
> > > > > "getent group mywingrp1" does not list any group members, even after
> > > > > "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> > > > > violation.
> > > >
> > > > Not a bug.  Two problems:
> > > >
> > > > - Getting members of a group can be an extremly costly operation
> > > >   in a domain or, worse, a domain forest, or even worse, if the
> > > >   domain or domain forest is remote.
> > > >
> > > > - Alonmg the same lines, getting members of a group can be extremly
> > > >   costly in big orgs with thousands of users.  Nobody want's to clutter
> > > >   up space with the list of members in the "Domain Users" group.
> > > >
> > > > - Permissions to enumerate members of a group are restricted.
> > > >   By default only admins and group members are allow to enumerate
> > > >   members and this can be restricted further by domain admins.
> > > >
> > > > Therefore we dropped even trying to populate gr_mem, considering
> > > > that even in its original form on Unix systems, it's used only
> > > > to add supplementary groups.  To do this right on Windows is even
> > > > more costly than blindly enumerating.
> > > >
> > > > It's not a bug, it's a feature :)
> > >
> > > Could you add an option to getent so that the full lookup can be
> > > requested via command line, pls?
> >
> > That's not possible.  getent just calls getpwent/getgrent.
> >
> > > Always editing /etc/nsswitch.conf
> > > forth and back is not a elegant solution, aside from race conditions
> > > with other users on a system
> >
> > So, here we go again.
> >
> > - What exactly are you trying to accomplish by enumerating the accounts?
> >   Maybe you won't actually need it for your task at hand.
> >
> > - Why do you have to change nsswitch.conf "back and forth"?
> >   Just change it once and you're done.
> >
> >
> > Corinna
>
> Hello
> > > Dan Shelton - Cluster Specialist Win/Lin/Bsd
>
> > > Always editing /etc/nsswitch.conf
> > > forth and back is not a elegant solution, aside from race conditions
> > > with other users on a system
>
> Please check the man page for getent.
>
> man getent
> getent --help
>
> You can use -s or --service to override the service used without
> editing nsswitch.conf.  The man page on Linux provides an example
> with a bit more details than the man page for getent under cygwin.
> https://www.man7.org/linux/man-pages/man1/getent.1.html

Is this feature supported under Cygwin /usr/bin/getent?

I tried it, but did not see any change. Even putting garbage into it,
e.g. /usr/bin/getent -s "$(man man)" group foo does not yield an
error.

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Brian Inglis]

On 2024-03-10 19:30, Dan Shelton via Cygwin wrote:
> On Sat, 9 Mar 2024 at 22:27, Glenn Strauss via Cygwin <cygwin@cygwin.com> wrote:
>> On Wed, Mar 06, 2024 at 02:01:06PM +0100, Corinna Vinschen via Cygwin wrote:
>>> On Mar  5 23:38, Dan Shelton via Cygwin wrote:
>>>> On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin wrote:
>>>>> On Feb 23 22:15, Dan Shelton via Cygwin wrote:
>>>>>> HOWEVER, there is another Cygwin bug:
>>>>>> "getent group mywingrp1" does not list any group members, even after
>>>>>> "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
>>>>>> violation.
>>>>>
>>>>> Not a bug.  Two problems:
>>>>>
>>>>> - Getting members of a group can be an extremly costly operation
>>>>>    in a domain or, worse, a domain forest, or even worse, if the
>>>>>    domain or domain forest is remote.
>>>>>
>>>>> - Alonmg the same lines, getting members of a group can be extremly
>>>>>    costly in big orgs with thousands of users.  Nobody want's to clutter
>>>>>    up space with the list of members in the "Domain Users" group.
>>>>>
>>>>> - Permissions to enumerate members of a group are restricted.
>>>>>    By default only admins and group members are allow to enumerate
>>>>>    members and this can be restricted further by domain admins.
>>>>>
>>>>> Therefore we dropped even trying to populate gr_mem, considering
>>>>> that even in its original form on Unix systems, it's used only
>>>>> to add supplementary groups.  To do this right on Windows is even
>>>>> more costly than blindly enumerating.
>>>>>
>>>>> It's not a bug, it's a feature :)
>>>>
>>>> Could you add an option to getent so that the full lookup can be
>>>> requested via command line, pls?
>>>
>>> That's not possible.  getent just calls getpwent/getgrent.
>>>
>>>> Always editing /etc/nsswitch.conf
>>>> forth and back is not a elegant solution, aside from race conditions
>>>> with other users on a system
>>>
>>> So, here we go again.
>>>
>>> - What exactly are you trying to accomplish by enumerating the accounts?
>>>    Maybe you won't actually need it for your task at hand.
>>>
>>> - Why do you have to change nsswitch.conf "back and forth"?
>>>    Just change it once and you're done.

>>>> Always editing /etc/nsswitch.conf
>>>> forth and back is not a elegant solution, aside from race conditions
>>>> with other users on a system

Plus you need to terminate all processes in a tree and/or restart cygserver to 
pick up any changed information.

>> Please check the man page for getent.
>>
>> man getent
>> getent --help
>>
>> You can use -s or --service to override the service used without
>> editing nsswitch.conf.  The man page on Linux provides an example
>> with a bit more details than the man page for getent under cygwin.
>> https://www.man7.org/linux/man-pages/man1/getent.1.html

That web page does not even define services (and it is not the same as the 
services database), better info is available on the linked page:

	https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html

but none of those Linux services/sources apply on Cygwin.

The Cygwin getent man page does not document the current implementation; and
getent --help does not explain what a service configuration is: possibly the 
same as the line you specify after db_enum, or maybe just one source?

Rely on /etc/nsswitch.conf; a bit better explanation is available if you install 
Cygwin man-pages-linux then run:

	$ man -m linux getent

and, as above, none of those Linux services/sources apply on Cygwin.

> Is this feature supported under Cygwin /usr/bin/getent?
> 
> I tried it, but did not see any change. Even putting garbage into it,
> e.g. /usr/bin/getent -s "$(man man)" group foo does not yield an
> error.

This facility is a generic lookup using certain sets of functions accessing 
information from various sources defined in comments in Cygwin's 
/etc/nsswitch.conf, so if you pass in nonsense, you just will not get a match, 
and nothing will be output.

You will only get an error if information required to perform a lookup is 
unrecognized, for example option, database, or missing, for example key, where 
enumeration is not supported.

Perhaps using meaningful commands on existing but elusive groups above like:

	$ getent -s local group mywingrp1

	$ getent -s primary group mywingrp1

may produce results that match what you should expect, and possibly even

	$ getent -s 'local primary' group mywingrp1

may produce output.

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

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Mar  9 16:26, Glenn Strauss via Cygwin wrote:
> On Wed, Mar 06, 2024 at 02:01:06PM +0100, Corinna Vinschen via Cygwin wrote:
> > On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> > > On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin
> > > <cygwin@cygwin.com> wrote:
> > > >
> > > > On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> > > > > HOWEVER, there is another Cygwin bug:
> > > > > "getent group mywingrp1" does not list any group members, even after
> > > > > "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> > > > > violation.
> > > >
> > > > Not a bug.  Two problems:
> > > >
> > > > - Getting members of a group can be an extremly costly operation
> > > >   in a domain or, worse, a domain forest, or even worse, if the
> > > >   domain or domain forest is remote.
> > > >
> > > > - Alonmg the same lines, getting members of a group can be extremly
> > > >   costly in big orgs with thousands of users.  Nobody want's to clutter
> > > >   up space with the list of members in the "Domain Users" group.
> > > >
> > > > - Permissions to enumerate members of a group are restricted.
> > > >   By default only admins and group members are allow to enumerate
> > > >   members and this can be restricted further by domain admins.
> > > >
> > > > Therefore we dropped even trying to populate gr_mem, considering
> > > > that even in its original form on Unix systems, it's used only
> > > > to add supplementary groups.  To do this right on Windows is even
> > > > more costly than blindly enumerating.
> > > >
> > > > It's not a bug, it's a feature :)
> > > 
> > > Could you add an option to getent so that the full lookup can be
> > > requested via command line, pls?
> > 
> > That's not possible.  getent just calls getpwent/getgrent.
> > 
> > > Always editing /etc/nsswitch.conf
> > > forth and back is not a elegant solution, aside from race conditions
> > > with other users on a system
> > 
> > So, here we go again.
> > 
> > - What exactly are you trying to accomplish by enumerating the accounts?
> >   Maybe you won't actually need it for your task at hand.
> > 
> > - Why do you have to change nsswitch.conf "back and forth"?
> >   Just change it once and you're done.
> > 
> > 
> > Corinna
> 
> Hello
> > > Dan Shelton - Cluster Specialist Win/Lin/Bsd
> 
> > > Always editing /etc/nsswitch.conf
> > > forth and back is not a elegant solution, aside from race conditions
> > > with other users on a system
> 
> Please check the man page for getent.
> 
> man getent
> getent --help
> 
> You can use -s or --service to override the service used without
> editing nsswitch.conf.  The man page on Linux provides an example
> with a bit more details than the man page for getent under cygwin.
> https://www.man7.org/linux/man-pages/man1/getent.1.html

The -s option is just available for compatibility, but otherwise a no-op
on Cygwin.  The -i option works as upstream, -w is a Cygwin-only option.

The Cygwin getent.1 man page is a bit old, given it's taken from
upstream and just slightly adapted from glibc 2.18.90, a good 10 years
ago.  The upstream man page at the time did not document the options for
some reason.  These days it documents the options, so we could fetch
this and create a new manpage from there.


Corinna

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen]

On Mar 11 02:28, Dan Shelton via Cygwin wrote:
> On Wed, 6 Mar 2024 at 14:01, Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> > On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> > > Always editing /etc/nsswitch.conf
> > > forth and back is not a elegant solution, aside from race conditions
> > > with other users on a system
> >
> > So, here we go again.
> >
> > - What exactly are you trying to accomplish by enumerating the accounts?
> >   Maybe you won't actually need it for your task at hand.
> 
> We're trying to do several things, including but not limited to:
> - Finding which local groups exist. Part of our customer software
> expects that certain groups exist. Unfortunately the group names vary
> between installations, and sometimes names are prefixed with site
> names. Trying to do all permutations with just getent passwd
> $iteration means too many combinations (>= 4000000). So just
> enumerating all local groups with getent group would be the way to go.

Then just change /etc/nsswitch.conf to enumerate "local" as well
and be done with it.

You can even go so far as to use the Windows enumerator, i.e.,

  $ net localgroup

and than script it to use its output as input to getent group
for only the groups you really need info for.


Corinna

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Dan Shelton]

On Mon, 11 Mar 2024 at 17:57, Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>
> On Mar 11 02:28, Dan Shelton via Cygwin wrote:
> > On Wed, 6 Mar 2024 at 14:01, Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > > On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> > > > Always editing /etc/nsswitch.conf
> > > > forth and back is not a elegant solution, aside from race conditions
> > > > with other users on a system
> > >
> > > So, here we go again.
> > >
> > > - What exactly are you trying to accomplish by enumerating the accounts?
> > >   Maybe you won't actually need it for your task at hand.
> >
> > We're trying to do several things, including but not limited to:
> > - Finding which local groups exist. Part of our customer software
> > expects that certain groups exist. Unfortunately the group names vary
> > between installations, and sometimes names are prefixed with site
> > names. Trying to do all permutations with just getent passwd
> > $iteration means too many combinations (>= 4000000). So just
> > enumerating all local groups with getent group would be the way to go.
>
> Then just change /etc/nsswitch.conf to enumerate "local" as well
> and be done with it.

That file is read-only for some customer installations, and we are not
allowed to touch it.

>
> You can even go so far as to use the Windows enumerator, i.e.,
>
>   $ net localgroup
>
> and than script it to use its output as input to getent group
> for only the groups you really need info for.

net localgroup changes layout and messages per system locale. That
might be nice to watch as a human user, but impossible to write a
parser. That damn thing does not honor LC_ALL, and I am now basically
forced to write custom parsers for each customers language.

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Andrey Repin]

Greetings, Dan Shelton!

>> Then just change /etc/nsswitch.conf to enumerate "local" as well
>> and be done with it.

> That file is read-only for some customer installations, and we are not
> allowed to touch it.

Then tell the system administrator to touch it.

>>
>> You can even go so far as to use the Windows enumerator, i.e.,
>>
>>   $ net localgroup
>>
>> and than script it to use its output as input to getent group
>> for only the groups you really need info for.

> net localgroup changes layout and messages per system locale. That
> might be nice to watch as a human user, but impossible to write a
> parser. That damn thing does not honor LC_ALL, and I am now basically
> forced to write custom parsers for each customers language.

Try `chcp 65001` before calling to it. It may behave better then.


-- 
With best regards,
Andrey Repin
Friday, April 26, 2024 12:02:05

Sorry for my terrible english...