Re: python3 3.9.18-1 hanging
On 20/02/2024 04:46, Marco Atzeri wrote: On 20/02/2024 03:46, Takashi Yano via Cygwin wrote: I hit probably the same issue while building pango1.0 1.51.2-1 with python39 3.9.18-2 (Test) installed. Several python3.9 processes are stalled and some of them cannot be terminated even with kill -9. Attaching gdb to them shows SIGSEGV in the thread whose stack is corrupted. The program counter is 0 as follows. Null function pointer dereference? Thread 12 "python3.9" received signal SIGSEGV, Segmentation fault. [Switching to Thread 19184.0x18ac] 0x in ?? () Another thread seems to stop in exit_thread() (winsup/cygwin/sigproc.cc). It may be due to SEGV. Downgrading it to 3.9.16-1 solves the issue. The problem seems to be somewhere between 3.16 and 3.17 it is also the upstream transition were several patches are not used anymore, so it seems the new inside path has some hidden consequence for Cygwin to avoid anymore ME TOO test failure, I removed python 3.18-1 and -2 completely Regards Marco -- 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
/usr/bin/sg in Cygwin?
Hello! Is there a package which provides /usr/bin/sg (execute shell commands in a different group)? 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
Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?
On Fri, 23 Feb 2024 at 19:45, Roland Mainz via Cygwin wrote: > > On Fri, Feb 23, 2024 at 4:47 PM Corinna Vinschen via Cygwin > wrote: > > On Feb 23 14:03, Roland Mainz via Cygwin wrote: > > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin > > > 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-66123-4220857270-1003:197611: > WINHOST1:~$ getent group cygwingrp2 > cygwingrp2:S-1-5-21-3286904461-66123-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
Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?
On Fri, Feb 23, 2024 at 4:47 PM Corinna Vinschen via Cygwin wrote: > On Feb 23 14:03, Roland Mainz via Cygwin wrote: > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin > > 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-66123-4220857270-1003:197611: WINHOST1:~$ getent group cygwingrp2 cygwingrp2:S-1-5-21-3286904461-66123-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
Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?
On Feb 23 14:03, Roland Mainz via Cygwin wrote: > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin > 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 -- 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
Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?
On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin 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.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
Re: BUG: Cygwin getent group refuses to list group added with net localgroup mygrp1 /add
On Feb 23 09:10, Dan Shelton via Cygwin wrote: > On Tue, 20 Feb 2024 at 21:45, Corinna Vinschen via Cygwin > wrote: > > > > On Feb 20 17:24, Dan Shelton via Cygwin wrote: > > > On Tue, 20 Feb 2024 at 10:57, Corinna Vinschen via Cygwin > > > wrote: > > > > > > > > On Feb 20 05:13, Dan Shelton via Cygwin wrote: > > > > > Hello! > > > > > > > > > > I think I found a rather nasty bug: > > > > > 1. Add a new group with "net localgroup mygrp1 /add" > > > > > 2. Then list all groups with "getent group", the new group mygrp1 will > > > > > not show up. "getent group mygrp1" will list it, but this is useless > > > > > in my case, as I need the group listed by "getent group" > > > > > > > > I guess we can rule out a domain controller but is this a standalone > > > > machine or a domain member machine? > > > > > > Standalone test machine, stock Windows 10 installed 2 days ago, > > > current patches, Cygwin 3.5 from 2 days ago. > > > > > > > > > > > What's the setting of your /etc/nsswitch.conf? > > > > > > Only comments in that file, i.e. empty > > > > Please set the db_enum: line to > > > > db_enum: all > > > > and try again after exiting from the shell window. Have a look at > > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch > > for the settings. By default account enumeration only returns > > the bare minimum for speed. > > > > Btw, there *is* a bug in that code, but it affects only domain > > menber machines, afaics. > > I saw you did a couple of commits related to "getent group". Is any of > these commits fixing the problem that a new Win32 local group created > with "net localgroup mygrp1 /add" does not show up in the output of > "getent group"? Did you read my previous reply and tried what I wrote? Corinna -- 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
Re: BUG: Cygwin getent group refuses to list group added with net localgroup mygrp1 /add
On Tue, 20 Feb 2024 at 21:45, Corinna Vinschen via Cygwin wrote: > > On Feb 20 17:24, Dan Shelton via Cygwin wrote: > > On Tue, 20 Feb 2024 at 10:57, Corinna Vinschen via Cygwin > > wrote: > > > > > > On Feb 20 05:13, Dan Shelton via Cygwin wrote: > > > > Hello! > > > > > > > > I think I found a rather nasty bug: > > > > 1. Add a new group with "net localgroup mygrp1 /add" > > > > 2. Then list all groups with "getent group", the new group mygrp1 will > > > > not show up. "getent group mygrp1" will list it, but this is useless > > > > in my case, as I need the group listed by "getent group" > > > > > > I guess we can rule out a domain controller but is this a standalone > > > machine or a domain member machine? > > > > Standalone test machine, stock Windows 10 installed 2 days ago, > > current patches, Cygwin 3.5 from 2 days ago. > > > > > > > > What's the setting of your /etc/nsswitch.conf? > > > > Only comments in that file, i.e. empty > > Please set the db_enum: line to > > db_enum: all > > and try again after exiting from the shell window. Have a look at > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch > for the settings. By default account enumeration only returns > the bare minimum for speed. > > Btw, there *is* a bug in that code, but it affects only domain > menber machines, afaics. I saw you did a couple of commits related to "getent group". Is any of these commits fixing the problem that a new Win32 local group created with "net localgroup mygrp1 /add" does not show up in the output of "getent group"? 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
