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

Roland Mainz roland.mainz@nrubsig.org
Fri Feb 23 18:45:20 GMT 2024

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
WINHOST1:~$ getent group cygwingrp2
---- 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 :-)


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

More information about the Cygwin mailing list