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 -- 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
