Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

2024-03-09 Thread Glenn Strauss via Cygwin
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

-- 
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: arc4random does not reseed after using fork()

2024-01-26 Thread Glenn Strauss via Cygwin
> While testing ksh93u+m's recently added SRANDOM variable[1], I have
> discovered a bug in Cygwin's arc4random function. After using fork(),
> arc4random does not reseed itself, which causes the results to become
> predictable[2]. Below is a test case C program exhibiting the bug:
> 
> ...
> 
> [1]: https://github.com/ksh93/ksh/commit/00b296c
> [2]: https://github.com/ksh93/ksh/issues/711

FYI: There was a thread in Nov 2023 about rand() which might be related.

rand is not ISO C compliant in Cygwin
https://cygwin.com/pipermail/cygwin/2023-November/254735.html

conclusion of that thread:
https://cygwin.com/pipermail/cygwin/2023-November/254764.html

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


How to test Cygwin 3.5 using github actions

2024-01-17 Thread Glenn Strauss via Cygwin
On Wed, Jan 17, 2024 at 12:44:32PM +0100, Corinna Vinschen via Cygwin wrote:
> Hi folks,
> 
> we're planning to release Cygwin 3.5 end of this month (Jan 2024) if
> nothing serious crops up.

Was: Re: [ANNOUNCEMENT] Cygwin 3.5 is coming soon, please test!

Corinna: Cygwin 3.5 works fine when tested with the lighttpd test suite.


For others who might try something similar on their own repos:

How to test Cygwin 3.5 using github actions
---

Starting with:
  https://github.com/cygwin/cygwin-install-action/
  (Thanks Adam Dinwoodie, Jon Turney, Konrad Gräfe)

I added to my Windows-Cygwin job:

  - name: Update
shell: powershell
run: |
  # 
(https://github.com/cygwin/cygwin-install-action/blob/master/action.yml)
  Invoke-WebRequest https://cygwin.com/setup-x86_64.exe -OutFile 
C:\setup.exe
  # because setup is a Windows GUI app, make it part of a pipeline to 
make
  # PowerShell wait for it to exit
  & C:\setup.exe -qgnO -t | Out-Default

Hey Jon, would you accept a pull request to add an option to add -t to
the call to setup.exe in cygwin-install-action?

For lighttpd, I added the above to
https://github.com/lighttpd/lighttpd1.4/blob/master/.github/workflows/pr.yml#L190

The whole lighttpd Windows-Cygwin job currently looks like this:

  Windows-Cygwin:
runs-on: windows-latest
env:
  CYGWIN: winsymlinks:native
steps:
  - run: git config --global core.autocrlf input
  - uses: actions/checkout@v4
  - uses: cygwin/cygwin-install-action@master
with:
  packages: >
autoconf automake libtool m4 make
cmake meson ninja scons
gcc-g++ git pkgconf perl
libpcre2-devel
libnettle-devel gnutls-devel mbedtls-devel libnss-devel libssl-devel
libbrotli-devel libdeflate-devel zlib-devel libzstd-devel
libsasl2-devel libkrb5-devel libdbi-devel openldap-devel
libmariadb-devel libpq-devel
libmaxminddb-devel libunwind-devel lua-devel lua5.1-devel
libxml2-devel libuuid-devel libsqlite3-devel
  - name: Update
shell: powershell
run: |
  # 
(https://github.com/cygwin/cygwin-install-action/blob/master/action.yml)
  Invoke-WebRequest https://cygwin.com/setup-x86_64.exe -OutFile 
C:\setup.exe
  # because setup is a Windows GUI app, make it part of a pipeline to 
make
  # PowerShell wait for it to exit
  & C:\setup.exe -qgnO -t | Out-Default
  - name: Compile and Test
#shell: C:\cygwin\bin\bash.exe --noprofile --norc -o igncr -eo pipefail 
'{0}'
shell: C:\cygwin\bin\bash.exe --login -o igncr -eo pipefail '{0}'
run: |
  set -e
  export PATH=/usr/bin:$(cygpath ${SYSTEMROOT})/system32
  # lighttpd-specific build and test commands:
  export NO_PAM=1 NO_UNWIND=1 NO_WOLFSSL=1
  cd "${{github.workspace}}" && scripts/ci-build.sh autobuild

Cheers, Glenn

-- 
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: rand is not ISO C compliant in Cygwin

2023-11-13 Thread Glenn Strauss via Cygwin
On Mon, Nov 13, 2023 at 10:33:48PM +0100, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > I took a look into POSIX and I'm a bit puzzled now.  From
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html
> 
> Part of the confusion is that POSIX and ISO C have slightly different
> wording. This POSIX page says:
>"The functionality described on this reference page is aligned
> with the ISO C standard. Any conflict between the requirements
> described here and the ISO C standard is unintentional. This
> volume of POSIX.1-2017 defers to the ISO C standard."
> 
> In ISO C 99 § 7.20.2, the only relevant sentence is:
> 
>   "The srand function uses the argument as a seed for a new sequence
>of pseudo-random numbers to be returned by subsequent calls to rand.
>If srand is then called with the same seed value, the sequence of
>pseudo-random numbers shall be repeated."
> 
> In ISO C 11 § 7.22.2 and ISO C 17 § 7.22.2, additionally two sentences
> were inserted:
> 
>   "The rand function is not required to avoid data races with other
>calls to pseudo-random sequence generation functions."
> 
>   "The srand function is not required to avoid data races with other
>calls to pseudo-random sequence generation functions."
> 
> ISO C 23 (which is still is draft state, but compared to the draft
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf I cannot
> see any change regarding rand() in the changes summary
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3148.doc) has the
> same wording.
> 
> POSIX does not have these two sentences, but instead has:
> 
>   "The rand() function need not be thread-safe."

I read the above as requiring *reentrancy*, but not *thread-safety*.

If multiple threads are accessing rand() and rand() accesses global
state, the global state should not get corrupted; the sequence
generated by rand() should remain intact.  Since thread-safety is not
guaranteed, is it theoretically possible that multiple threads enter
rand() at nearly the same time and both get the *same* random value in
the sequence.  (Whether or not that is undesirable behavior is
application-specific.)  A mutex can avoid this theoretical duplication,
as can using thread-local state (with difference seeds) instead of
global state.  If the seed value is the same in multiple threads using
thread-local state, the sequence of random values generated in each
thread will be repeated in each thread.  This may be surprising behavior
to some when srand() is called, then multiple threads spawned, and each
thread subsequently gets the same sequence of values from rand().

If the global state is a single item and atomics can be used to access
and update the global state, then an implemntation can use atomics
instead of mutexes to achieve thread-safety, which is allowed by the
standards, but not required for rand().

Cheers, Glenn

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


[ANNOUNCEMENT] Updated: lighttpd-1.4.71

2023-05-27 Thread Glenn Strauss via Cygwin
Version 1.4.71-1 of "lighttpd" has been uploaded.

lighttpd is a secure, fast, modular web server with low resource usage

lighttpd 1.4.71:
  bugfixes and portability; HTTP/2 support separated to mod_h2 module

Source: https://git.lighttpd.net/lighttpd/lighttpd1.4.git/
News: https://www.lighttpd.net/
License: BSD 3-clause
  https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/COPYING

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


[ANNOUNCEMENT] Updated: lighttpd-1.4.69

2023-02-12 Thread Glenn Strauss via Cygwin
Version 1.4.69-1 of "lighttpd" has been uploaded.

lighttpd is a secure, fast, modular web server with low resource usage

lighttpd 1.4.69: bugfixes, portability

Source: https://git.lighttpd.net/lighttpd/lighttpd1.4.git/
News: https://www.lighttpd.net/
License: BSD 3-clause
  https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/COPYING

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


[ANNOUNCEMENT] Updated: lighttpd-1.4.68

2023-01-03 Thread Glenn Strauss via Cygwin
Version 1.4.68-1 of "lighttpd" has been uploaded.

lighttpd is a secure, fast, modular web server with low resource usage

lighttpd 1.4.68:
* stronger TLS defaults (as previously announced)
* KTLS sendfile in mod_openssl and mod_gnutls, if available and enabled
* removal of deprecated modules

Source: https://git.lighttpd.net/lighttpd/lighttpd1.4.git/
News: https://www.lighttpd.net/
License: BSD 3-clause
  https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/master/COPYING

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