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