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.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
