Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?
On 2024-03-10 19:30, Dan Shelton via Cygwin wrote: On Sat, 9 Mar 2024 at 22:27, Glenn Strauss via Cygwin wrote: On Wed, Mar 06, 2024 at 02:01:06PM +0100, Corinna Vinschen via Cygwin wrote: On Mar 5 23:38, Dan Shelton via Cygwin wrote: On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin wrote: On Feb 23 22:15, Dan Shelton via Cygwin wrote: 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. Not a bug. Two problems: - Getting members of a group can be an extremly costly operation in a domain or, worse, a domain forest, or even worse, if the domain or domain forest is remote. - Alonmg the same lines, getting members of a group can be extremly costly in big orgs with thousands of users. Nobody want's to clutter up space with the list of members in the "Domain Users" group. - Permissions to enumerate members of a group are restricted. By default only admins and group members are allow to enumerate members and this can be restricted further by domain admins. Therefore we dropped even trying to populate gr_mem, considering that even in its original form on Unix systems, it's used only to add supplementary groups. To do this right on Windows is even more costly than blindly enumerating. It's not a bug, it's a feature :) Could you add an option to getent so that the full lookup can be requested via command line, pls? That's not possible. getent just calls getpwent/getgrent. Always editing /etc/nsswitch.conf forth and back is not a elegant solution, aside from race conditions with other users on a system So, here we go again. - What exactly are you trying to accomplish by enumerating the accounts? Maybe you won't actually need it for your task at hand. - Why do you have to change nsswitch.conf "back and forth"? Just change it once and you're done. Always editing /etc/nsswitch.conf forth and back is not a elegant solution, aside from race conditions with other users on a system Plus you need to terminate all processes in a tree and/or restart cygserver to pick up any changed information. Please check the man page for getent. man getent getent --help You can use -s or --service to override the service used without editing nsswitch.conf. The man page on Linux provides an example with a bit more details than the man page for getent under cygwin. https://www.man7.org/linux/man-pages/man1/getent.1.html That web page does not even define services (and it is not the same as the services database), better info is available on the linked page: https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html but none of those Linux services/sources apply on Cygwin. The Cygwin getent man page does not document the current implementation; and getent --help does not explain what a service configuration is: possibly the same as the line you specify after db_enum, or maybe just one source? Rely on /etc/nsswitch.conf; a bit better explanation is available if you install Cygwin man-pages-linux then run: $ man -m linux getent and, as above, none of those Linux services/sources apply on Cygwin. Is this feature supported under Cygwin /usr/bin/getent? I tried it, but did not see any change. Even putting garbage into it, e.g. /usr/bin/getent -s "$(man man)" group foo does not yield an error. This facility is a generic lookup using certain sets of functions accessing information from various sources defined in comments in Cygwin's /etc/nsswitch.conf, so if you pass in nonsense, you just will not get a match, and nothing will be output. You will only get an error if information required to perform a lookup is unrecognized, for example option, database, or missing, for example key, where enumeration is not supported. Perhaps using meaningful commands on existing but elusive groups above like: $ getent -s local group mywingrp1 $ getent -s primary group mywingrp1 may produce results that match what you should expect, and possibly even $ getent -s 'local primary' group mywingrp1 may produce output. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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 Sat, 9 Mar 2024 at 22:27, Glenn Strauss via Cygwin wrote: > > On Wed, Mar 06, 2024 at 02:01:06PM +0100, Corinna Vinschen via Cygwin wrote: > > On Mar 5 23:38, Dan Shelton via Cygwin wrote: > > > On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin > > > wrote: > > > > > > > > On Feb 23 22:15, Dan Shelton via Cygwin wrote: > > > > > 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. > > > > > > > > Not a bug. Two problems: > > > > > > > > - Getting members of a group can be an extremly costly operation > > > > in a domain or, worse, a domain forest, or even worse, if the > > > > domain or domain forest is remote. > > > > > > > > - Alonmg the same lines, getting members of a group can be extremly > > > > costly in big orgs with thousands of users. Nobody want's to clutter > > > > up space with the list of members in the "Domain Users" group. > > > > > > > > - Permissions to enumerate members of a group are restricted. > > > > By default only admins and group members are allow to enumerate > > > > members and this can be restricted further by domain admins. > > > > > > > > Therefore we dropped even trying to populate gr_mem, considering > > > > that even in its original form on Unix systems, it's used only > > > > to add supplementary groups. To do this right on Windows is even > > > > more costly than blindly enumerating. > > > > > > > > It's not a bug, it's a feature :) > > > > > > Could you add an option to getent so that the full lookup can be > > > requested via command line, pls? > > > > That's not possible. getent just calls getpwent/getgrent. > > > > > Always editing /etc/nsswitch.conf > > > forth and back is not a elegant solution, aside from race conditions > > > with other users on a system > > > > So, here we go again. > > > > - What exactly are you trying to accomplish by enumerating the accounts? > > Maybe you won't actually need it for your task at hand. > > > > - Why do you have to change nsswitch.conf "back and forth"? > > Just change it once and you're done. > > > > > > Corinna > > Hello > > > Dan Shelton - Cluster Specialist Win/Lin/Bsd > > > > Always editing /etc/nsswitch.conf > > > forth and back is not a elegant solution, aside from race conditions > > > with other users on a system > > Please check the man page for getent. > > man getent > getent --help > > You can use -s or --service to override the service used without > editing nsswitch.conf. The man page on Linux provides an example > with a bit more details than the man page for getent under cygwin. > https://www.man7.org/linux/man-pages/man1/getent.1.html Is this feature supported under Cygwin /usr/bin/getent? I tried it, but did not see any change. Even putting garbage into it, e.g. /usr/bin/getent -s "$(man man)" group foo does not yield an error. 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 Wed, 6 Mar 2024 at 14:01, Corinna Vinschen via Cygwin wrote: > > On Mar 5 23:38, Dan Shelton via Cygwin wrote: > > On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin > > wrote: > > > > > > On Feb 23 22:15, Dan Shelton via Cygwin wrote: > > > > 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. > > > > > > Not a bug. Two problems: > > > > > > - Getting members of a group can be an extremly costly operation > > > in a domain or, worse, a domain forest, or even worse, if the > > > domain or domain forest is remote. > > > > > > - Alonmg the same lines, getting members of a group can be extremly > > > costly in big orgs with thousands of users. Nobody want's to clutter > > > up space with the list of members in the "Domain Users" group. > > > > > > - Permissions to enumerate members of a group are restricted. > > > By default only admins and group members are allow to enumerate > > > members and this can be restricted further by domain admins. > > > > > > Therefore we dropped even trying to populate gr_mem, considering > > > that even in its original form on Unix systems, it's used only > > > to add supplementary groups. To do this right on Windows is even > > > more costly than blindly enumerating. > > > > > > It's not a bug, it's a feature :) > > > > Could you add an option to getent so that the full lookup can be > > requested via command line, pls? > > That's not possible. getent just calls getpwent/getgrent. What about environment variables? NSSWITCH_PATH=/etc/nsswitch.conf would be the default, and then let scripts customise it > > > Always editing /etc/nsswitch.conf > > forth and back is not a elegant solution, aside from race conditions > > with other users on a system > > So, here we go again. > > - What exactly are you trying to accomplish by enumerating the accounts? > Maybe you won't actually need it for your task at hand. We're trying to do several things, including but not limited to: - Finding which local groups exist. Part of our customer software expects that certain groups exist. Unfortunately the group names vary between installations, and sometimes names are prefixed with site names. Trying to do all permutations with just getent passwd $iteration means too many combinations (>= 400). So just enumerating all local groups with getent group would be the way to go. - get the uid and gid used by Cygwin, so the scripts can use them later for tar/pax and other scripts 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: tried Setup (2.931), but failed
On 3/10/2024 2:52 PM, Lester Ingber via Cygwin wrote: After mv ca-certificates.sh ca-certificates.sh.done I did a reinstall and now everything looked fine. Will that persist? I would think so. A reinstall will first remove the old .done file then run the scripts. If the underlying behavior is not different, it will still not rename the .sh to sh.done ... Best wishes - Eliot Moss -- 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: tried Setup (2.931), but failed
Marco: I moved my copy of ca-certificates.dash.done into /etc/postinstall/ just to keep track of common files. Thanks again. Lester -- 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: tried Setup (2.931), but failed
After mv ca-certificates.sh ca-certificates.sh.done I did a reinstall and now everything looked fine. Will that persist? Thanks. Lester -- 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: tried Setup (2.931), but failed
It was 0, so I did ca-certificates.sh ca-certificates.sh.done However, I then tried a reinstall of ca-certificates, and it failed the same way. -- 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: tried Setup (2.931), but failed
On 10/03/2024 17:32, Lester Ingber via Cygwin wrote: I see: lingber@LouiseLG /etc/postinstall$ source ca-certificates.sh + source ca-certificates.sh ++ '[' '!' -e /etc/pki/ca-trust/ca-legacy.conf ']' ++ '[' -f /etc/pki/ca-trust/ca-legacy.conf -a -x /usr/bin/diff ']' ++ /usr/bin/mkdir -p /var/cache/setup/etc/pki/ca-trust ++ /usr/bin/rm -f /var/cache/setup//etc/pki/ca-trust/ca-legacy.conf.diff ++ /usr/bin/diff -wut /etc/pki/ca-trust/ca-legacy.conf /etc/defaults/etc/pki/ca-trust/ca-legacy.conf ++ /usr/bin/ca-legacy install ++ /usr/bin/update-ca-trust forgot to ask, what is the output of $ echo $? after that ? if it is 0 you can just $ mv ca-certificates.sh ca-certificates.sh.done -- 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: tried Setup (2.931), but failed
I note that on my PC I see in /etc/postinstall/ ca-certificates.dash.done ca-certificates.sh.done but in my wife's PC I only see ca-certificates.sh -- 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: tried Setup (2.931), but failed
I see: lingber@LouiseLG /etc/postinstall$ source ca-certificates.sh + source ca-certificates.sh ++ '[' '!' -e /etc/pki/ca-trust/ca-legacy.conf ']' ++ '[' -f /etc/pki/ca-trust/ca-legacy.conf -a -x /usr/bin/diff ']' ++ /usr/bin/mkdir -p /var/cache/setup/etc/pki/ca-trust ++ /usr/bin/rm -f /var/cache/setup//etc/pki/ca-trust/ca-legacy.conf.diff ++ /usr/bin/diff -wut /etc/pki/ca-trust/ca-legacy.conf /etc/defaults/etc/pki/ca-trust/ca-legacy.conf ++ /usr/bin/ca-legacy install ++ /usr/bin/update-ca-trust -- 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: tried Setup (2.931), but failed
On 10.03.2024 12:56, Lester Ingber via Cygwin wrote: I tried Setup (2.931) but it too failed to fix ca-certificates. Lester Hi lester, Setup is not changing the script, so do not expect a change from that side can you please $ cd /etc/postinstall/ $ set -x $ source ca-certificates.sh On my system the output is: + source ca-certificates.sh ++ '[' '!' -e /etc/pki/ca-trust/ca-legacy.conf ']' ++ '[' -f /etc/pki/ca-trust/ca-legacy.conf -a -x /usr/bin/diff ']' ++ /usr/bin/mkdir -p /var/cache/setup/etc/pki/ca-trust ++ /usr/bin/rm -f /var/cache/setup//etc/pki/ca-trust/ca-legacy.conf.diff ++ /usr/bin/diff -wut /etc/pki/ca-trust/ca-legacy.conf /etc/defaults/etc/pki/ca-trust/ca-legacy.conf ++ /usr/bin/ca-legacy install ++ /usr/bin/update-ca-trust What is coming out from your ? 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
tried Setup (2.931), but failed
I tried Setup (2.931) but it too failed to fix ca-certificates. Lester -- 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: Non-Cygwin programs touching a pipe's read side makes the write side unselectable
On Sun, 10 Mar 2024 17:38:53 +0900 Takashi Yano wrote: > On Sun, 10 Mar 2024 05:49:43 + > wh wrote: > > Here's how to reproduce this behavior. > > > > In test3.pl: > > > > #!/usr/bin/perl > > my $wfds = ''; > > vec($wfds, fileno(STDOUT), 1) = 1; > > sleep 1; > > print STDERR "selecting\n"; > > select undef, $wfds, undef, undef; > > print STDERR "ready\n"; > > print "abc\n"; > > > > Then run: > > > > # curl is as shipped with Windows, /cygdrive/c/Windows/system32/curl > > ./test3.pl | (curl --version && cat) > > > > Expected result: > > > > curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN > > ... > > selecting > > ready > > abc > > > > Actual result: > > > > curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN > > ... > > selecting > > (hang) > > > > Using strace on perl, it ends with > > > >95 332358 [main] perl 733 clock_nanosleep: clock_nanosleep (1.0) > > 1004437 1336795 [main] perl 733 clock_nanosleep: 0 = clock_nanosleep(1, 0, > > 1.0, 0.d) > > 247 1337042 [main] perl 733 time: 1710048216 = time(0x7CA00) > > 1010 1338052 [main] perl 733 fhandler_console::write: 0xA00051B10, 10 > > 822 1338874 [main] perl 733 fhandler_console::write: 10 = > > fhandler_console::write(...) > > 203 1339077 [main] perl 733 write: 10 = write(2, 0xA00051B10, 10) > > 254 1339331 [main] perl 733 pselect: pselect (8, 0x0, 0xA000330E0, 0x0, > > 0x0, 0x0) > > 207 1339538 [main] perl 733 pselect: to NULL, us -1 > > 490 1340028 [main] perl 733 dtable::select_write: fd 1 > > 191 1340219 [main] perl 733 select: sel.always_ready 0 > > --- Process 6888 (pid: 733) thread 784 created > > 859 1341078 [pipesel] perl 733 cygthread::stub: thread 'pipesel', id > > 0x310, stack_ptr 0x2BBCCB0 > > 192 1341270 [main] perl 733 select_stuff::wait: m 3, us > > 18446744073709551615, wmfo_timeout -1 > > 196 1341466 [pipesel] perl 733 SetThreadName: SetThreadDescription() > > failed. 1000 > > > > Pipesel never comes back. > > > > Other info: > > > > - Replacing cat with tee (tee with no args is the same as cat) makes it > > work. tee reads in smaller chunks, while cat reads at the pipe buffer size. > > Comments in select.cc suggest this is important, but I don't understand it > > all. > > - Removing the curl makes it work > > - Using curl > - Using a Cygwin program instead of a non-Cygwin program e.g. id instead of > > curl makes it work > > - Removing the select confirms that nothing weird is breaking the pipe, and > > the "abc' shows up properly > > > > There was a report in MSYS2 > > https://github.com/msys2/msys2-runtime/issues/202 also about pipes to > > external programs, but there are some differences. In this scenario the > > non-Cygwin curl doesn't actually read anything from the pipe, and it should > > have exited before the select call. I tried a build of MSYS2 with their > > fix, and it still hangs in this way. > > Thanks for the report. I looked into this problem, and found the cause. > Let me consider how to fix that. I have submitted the patch for this issue. Now it is waiting for the review. Thanks. -- Takashi Yano -- 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: Non-Cygwin programs touching a pipe's read side makes the write side unselectable
On Sun, 10 Mar 2024 05:49:43 + wh wrote: > Here's how to reproduce this behavior. > > In test3.pl: > > #!/usr/bin/perl > my $wfds = ''; > vec($wfds, fileno(STDOUT), 1) = 1; > sleep 1; > print STDERR "selecting\n"; > select undef, $wfds, undef, undef; > print STDERR "ready\n"; > print "abc\n"; > > Then run: > > # curl is as shipped with Windows, /cygdrive/c/Windows/system32/curl > ./test3.pl | (curl --version && cat) > > Expected result: > > curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN > ... > selecting > ready > abc > > Actual result: > > curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN > ... > selecting > (hang) > > Using strace on perl, it ends with > >95 332358 [main] perl 733 clock_nanosleep: clock_nanosleep (1.0) > 1004437 1336795 [main] perl 733 clock_nanosleep: 0 = clock_nanosleep(1, 0, > 1.0, 0.d) > 247 1337042 [main] perl 733 time: 1710048216 = time(0x7CA00) > 1010 1338052 [main] perl 733 fhandler_console::write: 0xA00051B10, 10 > 822 1338874 [main] perl 733 fhandler_console::write: 10 = > fhandler_console::write(...) > 203 1339077 [main] perl 733 write: 10 = write(2, 0xA00051B10, 10) > 254 1339331 [main] perl 733 pselect: pselect (8, 0x0, 0xA000330E0, 0x0, > 0x0, 0x0) > 207 1339538 [main] perl 733 pselect: to NULL, us -1 > 490 1340028 [main] perl 733 dtable::select_write: fd 1 > 191 1340219 [main] perl 733 select: sel.always_ready 0 > --- Process 6888 (pid: 733) thread 784 created > 859 1341078 [pipesel] perl 733 cygthread::stub: thread 'pipesel', id 0x310, > stack_ptr 0x2BBCCB0 > 192 1341270 [main] perl 733 select_stuff::wait: m 3, us > 18446744073709551615, wmfo_timeout -1 > 196 1341466 [pipesel] perl 733 SetThreadName: SetThreadDescription() > failed. 1000 > > Pipesel never comes back. > > Other info: > > - Replacing cat with tee (tee with no args is the same as cat) makes it work. > tee reads in smaller chunks, while cat reads at the pipe buffer size. > Comments in select.cc suggest this is important, but I don't understand it > all. > - Removing the curl makes it work > - Using curl - Using a Cygwin program instead of a non-Cygwin program e.g. id instead of > curl makes it work > - Removing the select confirms that nothing weird is breaking the pipe, and > the "abc' shows up properly > > There was a report in MSYS2 https://github.com/msys2/msys2-runtime/issues/202 > also about pipes to external programs, but there are some differences. In > this scenario the non-Cygwin curl doesn't actually read anything from the > pipe, and it should have exited before the select call. I tried a build of > MSYS2 with their fix, and it still hangs in this way. Thanks for the report. I looked into this problem, and found the cause. Let me consider how to fix that. -- Takashi Yano -- 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