Re: [PATCH v4 3/3] Respect `db_home: env` even when no uid can be determined
On Apr 3 15:57, Johannes Schindelin wrote: > On Mon, 3 Apr 2023, Corinna Vinschen wrote: > > > So here is what is going on: > > > > > > - The domain is 'IIS APPPOOL' > > > > There's a domain, so why not pass it to the called function?> > > Sorry, I was unclear. This domain _is_ used when looking for the uid, but > then we run into a code path where the UID cannot be determined (because > the domain of the account is not the machine name and the machine is no > domain member). The clause in question is here: > https://github.com/cygwin/cygwin/blob/cygwin-3.4.6/winsup/cygwin/uinfo.cc#L2303-L2310. > The Cygwin runtime then returns -1 as UID. > > The _subsequent_ call to `getpwuid(-1)` is the one where we need to teach > Cygwin to respect `db_home: env`. This is the code path taken by OpenSSH. > And that code path only has an `arg.id` to work with (the `type` is > `ID_arg`), and that `arg.id` is invalid. There is no domain in that code > path that we could possibly pass to the `get_home()` method. That makes a lot of sense. However, wouldn't it be better to return some kind of valid uid, rather than working around uid -1? > > > - The name is the name of the Azure Web App > > > > > > - The sid is > > > 'S-1-5-82-3932326390-3052311582-2886778547-4123178866-1852425102' > > > > Oh well. These are basically the same thing as 1-5-80 service accounts. > > It would be great if we could handle them gracefully instead of > > special-case them in a piece of code we just reach because we don't > > handle them yet. > > True, but I don't really understand how they could be handled. We do something along these lines already for the AzureAD SIDs of type S-1-12-1-what-the-heck. If we do the same for the S-1-5-82 IIS AppPool accounts, we may be able to handle this more sanely. Just search for AzureAD in uinfo.cc. What do you think? Corinna > > Btw., one easy way out would be if we default to /home/ or > > /home/ rather than "/", isn't it? > > The default does not really matter, as the bug fix is about respecting > whatever the user has configured via the `HOME` variable, i.e. it's all > about the case when the default needs to be overridden, whatever that > default is. Right, that wouldn't help then. Corinna
Re: [PATCH v5 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts
On Apr 3 16:45, Johannes Schindelin wrote:
> We should not blindly set the home directory of the SYSTEM account (or
> of Microsoft accounts) to `/home/`, especially
> `/etc/nsswitch.conf` defines `db_home: env`, in which case we want to
> respect the `HOME` variable.
>
> Signed-off-by: Johannes Schindelin
> ---
> winsup/cygwin/uinfo.cc | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
> index baa670478d..d493d29b3b 100644
> --- a/winsup/cygwin/uinfo.cc
> +++ b/winsup/cygwin/uinfo.cc
> @@ -2234,7 +2234,11 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t
> , cyg_ldap *pldap)
>it to a well-known group here. */
>if (acc_type == SidTypeUser
> && (sid_sub_auth_count (sid) <= 3 || sid_id_auth (sid) == 11))
> - acc_type = SidTypeWellKnownGroup;
> + {
> + acc_type = SidTypeWellKnownGroup;
> + home = cygheap->pg.get_home ((PUSER_INFO_3) NULL, sid, dom, name,
> +fully_qualified_name);
> + }
>switch ((int) acc_type)
> {
> case SidTypeUser:
Pushed.
Thanks,
Corinna
Re: [PATCH v5 1/3] Allow deriving the current user's home directory via the HOME variable
On Apr 3 16:44, Johannes Schindelin wrote: > This patch hails from Git for Windows (where the Cygwin runtime is used > in the form of a slightly modified MSYS2 runtime), where it is a > well-established technique to let the `$HOME` variable define where the > current user's home directory is, falling back to `$HOMEDRIVE$HOMEPATH` > and `$USERPROFILE`. This patch is already merged. Corinna
Re: Cygwin starts take long since march. Three minutes to prompt.
On 2023-04-03 10:10, Thomas Schweikle via Cygwin wrote: Am Mo., 03.Apr..2023 um 17:48:03 schrieb Brian Inglis via Cygwin: On 2023-04-03 08:59, Thomas Schweikle via Cygwin wrote: Am Mo., 03.Apr..2023 um 16:47:42 schrieb Eliot Moss: On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: Cygwin shell takes about three minutes until the prompt is shown. Any idea how to find out the cause? I think the most common thing in the past had to do with probing remote mounts. You could try pruning paths and see what happens, or adjusting mount parameters. Mounts are: $ cat /proc/mounts C:/cygwin/bin /usr/bin ntfs binary,auto 1 1 C:/cygwin/lib /usr/lib ntfs binary,auto 1 1 C:/cygwin / ntfs binary,auto 1 1 C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 G: /cygdrive/g netapp binary,posix=0,user,noumount,auto 1 1 L: /cygdrive/l netapp binary,posix=0,user,noumount,auto 1 1 M: /cygdrive/m netapp binary,posix=0,user,noumount,auto 1 1 O: /cygdrive/o netapp binary,posix=0,user,noumount,auto 1 1 P: /cygdrive/p netapp binary,posix=0,user,noumount,auto 1 1 T: /cygdrive/t netapp binary,posix=0,user,noumount,auto 1 1 V: /cygdrive/v netapp binary,posix=0,user,noumount,auto 1 1 W: /cygdrive/w netapp binary,posix=0,user,noumount,auto 1 1 X: /cygdrive/x netapp binary,posix=0,user,noumount,auto 1 1 Y: /cygdrive/y netapp binary,posix=0,user,noumount,auto 1 1 Z: /cygdrive/z netapp binary,posix=0,user,noumount,auto 1 1 I've read somewhere noacl should be given for these mounts. Could not find it, even with a fresh installed cygwin on a fresh windows. Trying to reset acls to defaults for "C:\cygwin" gives lots of "access denied" errors, even if running as "Administrator" from an elevated shell. Tried both "cmd.exe" and "powershell.exe". Both did not allow to change acls. Seems as if "C:\cygwin" has lost ownership an some acls. Any idea to get them back in place for the whole tree? Should not need anything special: $ ls -dl / && getfacl / && icacls `cygpath -m /` # sanitized: drwxr-xr-x 1 $USER None 0 Mar 16 18:57 / # file: / # owner: $USER # group: None user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x C:/.../cygwin64 $HOSTNAME/$USER:(F) $HOSTNAME/None:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files $ ls -dl / && getfacl / && icacls `cygpath -m /` drwxr-xr-x 1 SYSTEM SYSTEM 0 Mar 23 13:44 / # file: / # owner: SYSTEM # group: SYSTEM user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x C:/cygwin NT-AUTORITÄT\SYSTEM:(F) NT-AUTORITÄT\SYSTEM:(RX) Jeder:(RX) ERSTELLER-BESITZER:(OI)(CI)(IO)(F) ERSTELLERGRUPPE:(OI)(CI)(IO)(RX) Jeder:(OI)(CI)(IO)(RX) 1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten. Is this ok? Not missing "Administrator"? Should not matter - depends on your setup. Those kinds of delays are often AD lookup for domain users and groups: see /etc/nsswitch.conf for settings, and consider running cygserver at system or Cygwin startup to preload and cache the info. $ cat /etc/nsswitch.conf # /etc/nsswitch.conf # # This file is read once by the first process in a # Cygwin process tree. # To pick up changes, restart all Cygwin processes. # For a description see https://cygwin.com/cygwin-ug- # net/ntsec.html#ntsec-mapping-nsswitch # # Defaults: # passwd: files db # group: files db # db_enum: cache builtin # db_home: /home/%U # db_shell: /bin/bash # db_gecos: It is at defaults. Perhaps read and change to suit your setup, and run cygserver: advantageous if you run a lot of Cygwin processes, or run many processes from cmd/Windows, not under a Cygwin mintty/shell process tree, where the top parent takes the hit. -- 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: [ITP] fish-doc
On 03/04/2023 16:16, Andrew Schulman via Cygwin-apps wrote: In the next release of fish, I'm going to split the package into fish and fish-doc. I can't remember if someone needs to add me to the maintainers list for the new fish-doc package, or if that happens automatically since they're created from the same source package. If someone does need to add me as the maintainer of fish-doc, can you please do that? No action is necessary, please go ahead. (Things get more complex if the install package name is already claimed by another source package, but that seems unlikely to be the case here.)
Re: Cygwin starts take long since march. Three minutes to prompt.
Am Mo., 03.Apr..2023 um 17:48:03 schrieb Brian Inglis via Cygwin: On 2023-04-03 08:59, Thomas Schweikle via Cygwin wrote: Am Mo., 03.Apr..2023 um 16:47:42 schrieb Eliot Moss: On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: Cygwin shell takes about three minutes until the prompt is shown. Any idea how to find out the cause? I think the most common thing in the past had to do with probing remote mounts. You could try pruning paths and see what happens, or adjusting mount parameters. Mounts are: $ cat /proc/mounts C:/cygwin/bin /usr/bin ntfs binary,auto 1 1 C:/cygwin/lib /usr/lib ntfs binary,auto 1 1 C:/cygwin / ntfs binary,auto 1 1 C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 G: /cygdrive/g netapp binary,posix=0,user,noumount,auto 1 1 L: /cygdrive/l netapp binary,posix=0,user,noumount,auto 1 1 M: /cygdrive/m netapp binary,posix=0,user,noumount,auto 1 1 O: /cygdrive/o netapp binary,posix=0,user,noumount,auto 1 1 P: /cygdrive/p netapp binary,posix=0,user,noumount,auto 1 1 T: /cygdrive/t netapp binary,posix=0,user,noumount,auto 1 1 V: /cygdrive/v netapp binary,posix=0,user,noumount,auto 1 1 W: /cygdrive/w netapp binary,posix=0,user,noumount,auto 1 1 X: /cygdrive/x netapp binary,posix=0,user,noumount,auto 1 1 Y: /cygdrive/y netapp binary,posix=0,user,noumount,auto 1 1 Z: /cygdrive/z netapp binary,posix=0,user,noumount,auto 1 1 I've read somewhere noacl should be given for these mounts. Could not find it, even with a fresh installed cygwin on a fresh windows. Trying to reset acls to defaults for "C:\cygwin" gives lots of "access denied" errors, even if running as "Administrator" from an elevated shell. Tried both "cmd.exe" and "powershell.exe". Both did not allow to change acls. Seems as if "C:\cygwin" has lost ownership an some acls. Any idea to get them back in place for the whole tree? Should not need anything special: $ ls -dl / && getfacl / && icacls `cygpath -m /` # sanitized: drwxr-xr-x 1 $USER None 0 Mar 16 18:57 / # file: / # owner: $USER # group: None user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x C:/.../cygwin64 $HOSTNAME/$USER:(F) $HOSTNAME/None:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files $ ls -dl / && getfacl / && icacls `cygpath -m /` drwxr-xr-x 1 SYSTEM SYSTEM 0 Mar 23 13:44 / # file: / # owner: SYSTEM # group: SYSTEM user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x C:/cygwin NT-AUTORITÄT\SYSTEM:(F) NT-AUTORITÄT\SYSTEM:(RX) Jeder:(RX) ERSTELLER-BESITZER:(OI)(CI)(IO)(F) ERSTELLERGRUPPE:(OI)(CI)(IO)(RX) Jeder:(OI)(CI)(IO)(RX) 1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler aufgetreten. Is this ok? Not missing "Administrator"? Those kinds of delays are often AD lookup for domain users and groups: see /etc/nsswitch.conf for settings, and consider running cygserver at system or Cygwin startup to preload and cache the info. $ cat /etc/nsswitch.conf # /etc/nsswitch.conf # #This file is read once by the first process in a #Cygwin process tree. #To pick up changes, restart all Cygwin processes. #For a description see https://cygwin.com/cygwin-ug- #net/ntsec.html#ntsec-mapping-nsswitch # # Defaults: # passwd: files db # group:files db # db_enum: cache builtin # db_home: /home/%U # db_shell: /bin/bash # db_gecos: It is at defaults. -- Thomas OpenPGP_0x27AE2304B4974851.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- 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: MSG_MORE socket.h flag
On 2023-04-03 04:56, Corinna Vinschen via Cygwin wrote: On Apr 2 00:19, Chance via Cygwin wrote: I've used cygwin in the past few years using the MSG_MORE flag when using some socket functions I have no idea how you did that. MSG_MORE was never actually supported by Cygwin, and the (more or less) equivalent MSG_PARTIAL flag was never exposed into Cygwin user space. but now it's not defined in cygwin\socket.h and It never was! I checked the history back until the year 2000. MSG_EOR is using the value of MSG_MORE (0x8000). Above that in the socket.h file there is a comment /* MSG_EOR is not supported. We use the MSG_PARTIAL flag here */. I understand this as meaning MSG_EOR now works as MSG_MORE would and that MSG_EOR is not usable. Just want some clarification on this. It just means we're using the bit value of MSG_PARTIAL to expose a MSG_EOR flag into user space. It was introduced in 2019 because of POSIX header file compatibility, but it's unsupported and always results in sedn/recv returning EOPNOTSUPP. I'm still puzzled where you got the MSG_MORE definition from, though. Not on BSD likely Linux: https://github.com/torvalds/linux/blob/master/include/linux/socket.h#L298 check for symlinks on poster's system? -- 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: Cygwin starts take long since march. Three minutes to prompt.
On 2023-04-03 08:59, Thomas Schweikle via Cygwin wrote: Am Mo., 03.Apr..2023 um 16:47:42 schrieb Eliot Moss: On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: Cygwin shell takes about three minutes until the prompt is shown. Any idea how to find out the cause? I think the most common thing in the past had to do with probing remote mounts. You could try pruning paths and see what happens, or adjusting mount parameters. Mounts are: $ cat /proc/mounts C:/cygwin/bin /usr/bin ntfs binary,auto 1 1 C:/cygwin/lib /usr/lib ntfs binary,auto 1 1 C:/cygwin / ntfs binary,auto 1 1 C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 G: /cygdrive/g netapp binary,posix=0,user,noumount,auto 1 1 L: /cygdrive/l netapp binary,posix=0,user,noumount,auto 1 1 M: /cygdrive/m netapp binary,posix=0,user,noumount,auto 1 1 O: /cygdrive/o netapp binary,posix=0,user,noumount,auto 1 1 P: /cygdrive/p netapp binary,posix=0,user,noumount,auto 1 1 T: /cygdrive/t netapp binary,posix=0,user,noumount,auto 1 1 V: /cygdrive/v netapp binary,posix=0,user,noumount,auto 1 1 W: /cygdrive/w netapp binary,posix=0,user,noumount,auto 1 1 X: /cygdrive/x netapp binary,posix=0,user,noumount,auto 1 1 Y: /cygdrive/y netapp binary,posix=0,user,noumount,auto 1 1 Z: /cygdrive/z netapp binary,posix=0,user,noumount,auto 1 1 I've read somewhere noacl should be given for these mounts. Could not find it, even with a fresh installed cygwin on a fresh windows. Trying to reset acls to defaults for "C:\cygwin" gives lots of "access denied" errors, even if running as "Administrator" from an elevated shell. Tried both "cmd.exe" and "powershell.exe". Both did not allow to change acls. Seems as if "C:\cygwin" has lost ownership an some acls. Any idea to get them back in place for the whole tree? Should not need anything special: $ ls -dl / && getfacl / && icacls `cygpath -m /`# sanitized: drwxr-xr-x 1 $USER None 0 Mar 16 18:57 / # file: / # owner: $USER # group: None user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x C:/.../cygwin64 $HOSTNAME/$USER:(F) $HOSTNAME/None:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files Those kinds of delays are often AD lookup for domain users and groups: see /etc/nsswitch.conf for settings, and consider running cygserver at system or Cygwin startup to preload and cache the info. -- 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: 'tac' trying to use "/tmp"; Error: not found
On 2023-04-02 21:22, marco atzeri wrote:
On Sun, Apr 2, 2023 at 9:43 PM Prof. Luis G. Uribe C. wrote:
*| 'tac' utility dies with a not found "/tmp" error. |*
It is preferable to copy the exact command(s) and output into your problem
report. Presumably the input is a pipe or non-seekable device which needs
buffered in a temp file.
I didn't see this problem in older 'tac' versions...
I created "/tmp" under my root directory:
*"c:\tmp"* (Windows 10), *to no avail*.
I make a *tmp* dir directly *above*, in the *parent's 'tac' dir*:
*"../tmp"*, at the same level as other usual folders like:
*bin*, *dev*, *etc*, *lib*, *sbin*...,
and now: *'**tac' works fine**!*
The /tmp directory needs to be created in the Cygwin POSIX root directory "/".
[I am surprised GNU tac does not yet use mmap where available, as an alternative
to seek, as mmap has been around for decades, since 4.4BSD, SysVr4, and Solaris
2.0 days, and should be faster on huge files.]
The expectation for the existence of /tmp directory is well founded
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
I assume by accident your installation pruned the directory.
I will not be surprised if other programs also complain, not only tac
You can point to another dir under a shell (or export the env var) using e.g.
$ export TMPDIR=${TMP:-${TEMP:-/tmp}}
or
$ TMPDIR=. tac ...
If you have Cygwin bash and coreutils installed, under bash or a similar shell
with brace expansion you can restore the install directories with:
$ /bin/mkdir -pv -m 0755 /{bin,dev,etc,lib} \
/usr/{bin,lib,local/{bin,etc,lib},src}
$ /bin/mkdir -pv -m 01777 /dev/{mqueue,shm} /etc/fstab.d \
/{home,{,usr/}tmp} /var/{log,run,tmp}
$ /bin/mkdir -pv -m 0666 /var/run/utmp
see:
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=blob;f=install.cc#l156
If the directories do not have the correct permissions, use chmod to fix them.
--
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
[ITP] fish-doc
In the next release of fish, I'm going to split the package into fish and fish-doc. I can't remember if someone needs to add me to the maintainers list for the new fish-doc package, or if that happens automatically since they're created from the same source package. If someone does need to add me as the maintainer of fish-doc, can you please do that? Thank you, Andrew
Re: Cygwin starts take long since march. Three minutes to prompt.
Hi! Am Mo., 03.Apr..2023 um 16:47:42 schrieb Eliot Moss: On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: Hi! Cygwin shell takes about three minutes until the prompt is shown. Any idea how to find out the cause? I think the most common thing in the past had to do with probing remote mounts. You could try pruning paths and see what happens, or adjusting mount parameters. Mounts are: $ cat /proc/mounts C:/cygwin/bin /usr/bin ntfs binary,auto 1 1 C:/cygwin/lib /usr/lib ntfs binary,auto 1 1 C:/cygwin / ntfs binary,auto 1 1 C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 G: /cygdrive/g netapp binary,posix=0,user,noumount,auto 1 1 L: /cygdrive/l netapp binary,posix=0,user,noumount,auto 1 1 M: /cygdrive/m netapp binary,posix=0,user,noumount,auto 1 1 O: /cygdrive/o netapp binary,posix=0,user,noumount,auto 1 1 P: /cygdrive/p netapp binary,posix=0,user,noumount,auto 1 1 T: /cygdrive/t netapp binary,posix=0,user,noumount,auto 1 1 V: /cygdrive/v netapp binary,posix=0,user,noumount,auto 1 1 W: /cygdrive/w netapp binary,posix=0,user,noumount,auto 1 1 X: /cygdrive/x netapp binary,posix=0,user,noumount,auto 1 1 Y: /cygdrive/y netapp binary,posix=0,user,noumount,auto 1 1 Z: /cygdrive/z netapp binary,posix=0,user,noumount,auto 1 1 I've read somewhere noacl should be given for these mounts. Could not find it, even with a fresh installed cygwin on a fresh windows. Trying to reset acls to defaults for "C:\cygwin" gives lots of "access denied" errors, even if running as "Administrator" from an elevated shell. Tried both "cmd.exe" and "powershell.exe". Both did not allow to change acls. Seems as if "C:\cygwin" has lost ownership an some acls. Any idea to get them back in place for the whole tree? -- Thomas OpenPGP_0x27AE2304B4974851.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- 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: Cygwin starts take long since march. Three minutes to prompt.
On 4/3/2023 10:38 AM, Thomas Schweikle via Cygwin wrote: Hi! Cygwin shell takes about three minutes until the prompt is shown. Any idea how to find out the cause? I think the most common thing in the past had to do with probing remote mounts. You could try pruning paths and see what happens, or adjusting mount parameters. Regards - 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
[PATCH v5 3/3] Respect `db_home: env` even when no uid can be determined
When we cannot figure out a uid for the current user, we should still
respect the `db_home: env` setting.
This is particularly important when programs like `ssh` look for the
home directory of the usr, the user overrode `HOME` to "help" Cygwin
determine where the home directory is. Cygwin should not ignore this.
One situation where we cannot determine a uid is when the domain
returned by `LookupAccountSid()` is not our machine name and at the same
time our machine is no domain member: In that case, we have nobody to
ask for the POSIX offset necessary to come up with the uid.
Azure Web Apps represent such a scenario, which can be verified e.g. in
a Kudu console (for details about Kudu consoles, see
https://github.com/projectkudu/kudu/wiki/Kudu-console): the domain is
`IIS APPPOOL`, the account name is the name of the Azure Web App, the
SID starts with 'S-1-5-82-`, and `pwdgrp::fetch_account_from_windows()`
runs into the code path where "[...] the domain returned by
LookupAccountSid is not our machine name, and if our machine is no
domain member, we lose. We have nobody to ask for the POSIX offset."
In such a scenario, OpenSSH's `getuid()` call will receive the return
value -1, and the subsequent `getpwuid()` call (whose return value's
`pw_dir` is used as home directory) needs to be forced to respect
`db_home: env`, which this here patch does.
Reported-by: David Ebbo
Signed-off-by: Johannes Schindelin
---
winsup/cygwin/uinfo.cc | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index d493d29b3b..b01bcff5cb 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -883,6 +883,8 @@ fetch_from_path (cyg_ldap *pldap, PUSER_INFO_3 ui, cygpsid
, PCWSTR str,
case L'u':
if (full_qualified)
{
+ if (!dom)
+ break;
w = wcpncpy (w, dom, we - w);
if (w < we)
*w++ = NSS_SEPARATOR_CHAR;
@@ -893,6 +895,8 @@ fetch_from_path (cyg_ldap *pldap, PUSER_INFO_3 ui, cygpsid
, PCWSTR str,
w = wcpncpy (w, name, we - w);
break;
case L'D':
+ if (!dom)
+ break;
w = wcpncpy (w, dom, we - w);
break;
case L'H':
@@ -2181,6 +2185,10 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t
, cyg_ldap *pldap)
{
/* Just some fake. */
sid = csid.create (99, 1, 0);
+ if (arg.id == cygheap->user.real_uid)
+ home = cygheap->pg.get_home ((PUSER_INFO_3) NULL,
+cygheap->user.sid(),
+NULL, NULL, false);
break;
}
else if (arg.id >= UNIX_POSIX_OFFSET)
@@ -2710,10 +2718,11 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t
, cyg_ldap *pldap)
logon. Unless it's the SYSTEM account. This conveniently allows to
logon interactively as SYSTEM for debugging purposes. */
else if (acc_type != SidTypeUser && sid != well_known_system_sid)
-__small_sprintf (linebuf, "%W:*:%u:%u:U-%W\\%W,%s:/:/sbin/nologin",
+__small_sprintf (linebuf, "%W:*:%u:%u:U-%W\\%W,%s:%s:/sbin/nologin",
posix_name, uid, gid,
dom, name,
-sid.string ((char *) sidstr));
+sid.string ((char *) sidstr),
+home ? home : "/");
else
__small_sprintf (linebuf, "%W:*:%u:%u:%s%sU-%W\\%W,%s:%s%W:%s",
posix_name, uid, gid,
--
2.40.0.windows.1
[PATCH v5 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts
We should not blindly set the home directory of the SYSTEM account (or
of Microsoft accounts) to `/home/`, especially
`/etc/nsswitch.conf` defines `db_home: env`, in which case we want to
respect the `HOME` variable.
Signed-off-by: Johannes Schindelin
---
winsup/cygwin/uinfo.cc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index baa670478d..d493d29b3b 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -2234,7 +2234,11 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t
, cyg_ldap *pldap)
it to a well-known group here. */
if (acc_type == SidTypeUser
&& (sid_sub_auth_count (sid) <= 3 || sid_id_auth (sid) == 11))
- acc_type = SidTypeWellKnownGroup;
+ {
+ acc_type = SidTypeWellKnownGroup;
+ home = cygheap->pg.get_home ((PUSER_INFO_3) NULL, sid, dom, name,
+ fully_qualified_name);
+ }
switch ((int) acc_type)
{
case SidTypeUser:
--
2.40.0.windows.1
[PATCH v5 1/3] Allow deriving the current user's home directory via the HOME variable
This patch hails from Git for Windows (where the Cygwin runtime is used
in the form of a slightly modified MSYS2 runtime), where it is a
well-established technique to let the `$HOME` variable define where the
current user's home directory is, falling back to `$HOMEDRIVE$HOMEPATH`
and `$USERPROFILE`.
The idea is that we want to share user-specific settings between
programs, whether they be Cygwin, MSYS2 or not. Unfortunately, we
cannot blindly activate the "db_home: windows" setting because in some
setups, the user's home directory is set to a hidden directory via an
UNC path (\\share\some\hidden\folder$) -- something many programs
cannot handle correctly, e.g. `cmd.exe` and other native Windows
applications that users want to employ as Git helpers.
The established technique is to allow setting the user's home directory
via the environment variables mentioned above: `$HOMEDRIVE$HOMEPATH` or
`$USERPROFILE`. This has the additional advantage that it is much
faster than querying the Windows user database.
Of course this scheme needs to be opt-in. For that reason, it needs
to be activated explicitly via `db_home: env` in `/etc/nsswitch.conf`.
Documentation-fixes-by: Corinna Vinschen
Signed-off-by: Johannes Schindelin
---
winsup/cygwin/local_includes/cygheap.h | 3 +-
winsup/cygwin/uinfo.cc | 51 ++
winsup/doc/ntsec.xml | 20 +-
3 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/local_includes/cygheap.h
b/winsup/cygwin/local_includes/cygheap.h
index d885ca1230..b6acdf7f18 100644
--- a/winsup/cygwin/local_includes/cygheap.h
+++ b/winsup/cygwin/local_includes/cygheap.h
@@ -358,7 +358,8 @@ public:
NSS_SCHEME_UNIX,
NSS_SCHEME_DESC,
NSS_SCHEME_PATH,
-NSS_SCHEME_FREEATTR
+NSS_SCHEME_FREEATTR,
+NSS_SCHEME_ENV
};
struct nss_scheme_t {
nss_scheme_method method;
diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 30df6db6d8..baa670478d 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -733,6 +733,8 @@ cygheap_pwdgrp::nss_init_line (const char *line)
scheme[idx].method = NSS_SCHEME_UNIX;
else if (NSS_CMP ("desc"))
scheme[idx].method = NSS_SCHEME_DESC;
+ else if (NSS_CMP ("env"))
+ scheme[idx].method = NSS_SCHEME_ENV;
else if (NSS_NCMP ("/"))
{
const char *e = c + strcspn (c, " \t");
@@ -921,6 +923,42 @@ fetch_from_path (cyg_ldap *pldap, PUSER_INFO_3 ui, cygpsid
, PCWSTR str,
return ret;
}
+static char *
+fetch_home_env (void)
+{
+ /* If `HOME` is set, prefer it */
+ const char *home = getenv ("HOME");
+ if (home)
+return strdup (home);
+
+ /* If `HOME` is unset, fall back to `HOMEDRIVE``HOMEPATH`
+ (without a directory separator, as `HOMEPATH` starts with one). */
+ const char *home_drive = getenv ("HOMEDRIVE");
+ if (home_drive)
+{
+ const char *home_path = getenv ("HOMEPATH");
+ if (home_path)
+ {
+ tmp_pathbuf tp;
+ char *p = tp.c_get (), *q;
+
+ // concatenate HOMEDRIVE and HOMEPATH
+ q = stpncpy (p, home_drive, NT_MAX_PATH);
+ strlcpy (q, home_path, NT_MAX_PATH - (q - p));
+ return (char *) cygwin_create_path (CCP_WIN_A_TO_POSIX, p);
+ }
+}
+
+ /* If neither `HOME` nor `HOMEDRIVE``HOMEPATH` are set, fall back
+ to `USERPROFILE`; In corporate setups, this might point to a
+ disconnected network share, hence this is the last fall back. */
+ home = getenv ("USERPROFILE");
+ if (home)
+return (char *) cygwin_create_path (CCP_WIN_A_TO_POSIX, home);
+
+ return NULL;
+}
+
char *
cygheap_pwdgrp::get_home (cyg_ldap *pldap, cygpsid , PCWSTR dom,
PCWSTR dnsdomain, PCWSTR name, bool full_qualified)
@@ -980,6 +1018,10 @@ cygheap_pwdgrp::get_home (cyg_ldap *pldap, cygpsid ,
PCWSTR dom,
}
}
break;
+ case NSS_SCHEME_ENV:
+ if (RtlEqualSid (sid, cygheap->user.sid ()))
+ home = fetch_home_env ();
+ break;
}
}
return home;
@@ -1012,6 +1054,10 @@ cygheap_pwdgrp::get_home (PUSER_INFO_3 ui, cygpsid ,
PCWSTR dom,
home = fetch_from_path (NULL, ui, sid, home_scheme[idx].attrib,
dom, NULL, name, full_qualified);
break;
+ case NSS_SCHEME_ENV:
+ if (RtlEqualSid (sid, cygheap->user.sid ()))
+ home = fetch_home_env ();
+ break;
}
}
return home;
@@ -1031,6 +1077,7 @@ cygheap_pwdgrp::get_shell (cyg_ldap *pldap, cygpsid ,
PCWSTR dom,
case NSS_SCHEME_FALLBACK:
return NULL;
case NSS_SCHEME_WINDOWS:
+ case NSS_SCHEME_ENV:
break;
case NSS_SCHEME_CYGWIN:
if (pldap->fetch_ad_account (sid, false, dnsdomain))
@@ -1095,6 +1142,7 @@
[PATCH v5 0/3] Support deriving the current user's home directory via HOME
This patch mini-series supports Git for Windows' default strategy to
determine the current user's home directory by looking at the
environment variable HOME, falling back to HOMEDRIVE and HOMEPATH, and
if these variables are also unset, to USERPROFILE.
This strategy is a quick method to determine the home directory,
certainly quicker than looking at LDAP, even more so when a domain
controller is unreachable and causes long hangs in Cygwin's startup.
This strategy also allows users to override the home directory easily
(e.g. in case that their real home directory is a network share that is
not all that well handled by some commands such as cmd.exe's cd
command).
Changes since v4:
- Squashed in Corinna's documentation fixes (read: patch 1 should not be
applied to Cygwin's main branch, it's presented here for backporting
purposes).
- Fixed the commit message of the second patch that mistakenly claimed
that Microsoft accounts would be associated with `/home/SYSTEM`.
- Completely overhauled the commit message of the third patch to motivate
much better why this fix is needed.
Changes since v3:
- Fixed the bug in v2 where `getenv("HOME")` would convert the value to
a Unix-y path and the `fetch_home_env()` function would then try to
convert it _again_.
- Disentangled the logic in `fetch_home_env()` instead of doing
everything in one big, honking, unreadable `if` condition.
- Commented the code in `fetch_home_env()`.
Changes since v2:
- Using `getenv()` and `cygwin_create_path()` instead of the
`GetEnvironmentVariableW()`/`cygwin_conv_path()` dance
- Adjusted the documentation to drive home that this only affects the
_current_ user's home directory
- Using the `PUSER_INFO_3` variant of `get_home()`
- Adjusted the commit messages
- Added another patch, to support "ad-hoc cloud accounts"
Johannes Schindelin (3):
Allow deriving the current user's home directory via the HOME variable
Respect `db_home` setting even for SYSTEM/Microsoft accounts
Respect `db_home: env` even when no uid can be determined
winsup/cygwin/local_includes/cygheap.h | 3 +-
winsup/cygwin/uinfo.cc | 70 --
winsup/doc/ntsec.xml | 20 +++-
3 files changed, 88 insertions(+), 5 deletions(-)
Range-diff:
1: 7a074997ea ! 1: e26cae9439 Allow deriving the current user's home
directory via the HOME variable
@@ Commit message
Of course this scheme needs to be opt-in. For that reason, it needs
to be activated explicitly via `db_home: env` in `/etc/nsswitch.conf`.
+Documentation-fixes-by: Corinna Vinschen
Signed-off-by: Johannes Schindelin
## winsup/cygwin/local_includes/cygheap.h ##
@@ winsup/cygwin/uinfo.cc: cygheap_pwdgrp::get_gecos (PUSER_INFO_3 ui,
cygpsid
if (ui)
## winsup/doc/ntsec.xml ##
+@@ winsup/doc/ntsec.xml: and on non-AD machines.
+
+
+
+-Four schemata are predefined, two schemata are variable. The predefined
++Five schemata are predefined, two schemata are variable. The predefined
+ schemata are the following:
+
+
@@ winsup/doc/ntsec.xml: schemata are the following:
See
for a more detailed description.
+
+env
-+Derives the home directory of the current user from the
-+environment variable HOME (falling back to
-+HOMEDRIVE\HOMEPATH and
-+USERPROFILE, in that order). This is faster
-+than the windows schema at the
-+expense of determining only the current user's home directory
-+correctly. This schema is skipped for any other account.
-+
++Utilizes the user's environment. This schema is only
supported
++for setting the home directory yet.
++See for
++the description.
+
@@ winsup/doc/ntsec.xml: of each schema when used with
db_home:
+environment variable HOME (falling back to
+HOMEDRIVE\HOMEPATH and
+USERPROFILE, in that order). This is faster
-+than the windows schema at the
++than the windows schema at the
+expense of determining only the current user's home directory
+correctly. This schema is skipped for any other account.
+
2: a70c77dc8f ! 2: 085d4dd8b6 Respect `db_home` setting even for
SYSTEM/Microsoft accounts
@@ Commit message
Respect `db_home` setting even for SYSTEM/Microsoft accounts
We should not blindly set the home directory of the SYSTEM account (or
-of Microsoft accounts) to /home/SYSTEM, especially not when that value
-disagrees with what is configured via the `db_home` line in the
-`/etc/nsswitch.conf` file.
+of Microsoft accounts) to `/home/`, especially
+`/etc/nsswitch.conf` defines `db_home: env`, in which case we want to
Cygwin starts take long since march. Three minutes to prompt.
Hi! Cygwin shell takes about three minutes until the prompt is shown. Any idea how to find out the cause? -- Thomas OpenPGP_0x27AE2304B4974851.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- 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: [PATCH v4 3/3] Respect `db_home: env` even when no uid can be determined
Hi Corinna, On Mon, 3 Apr 2023, Corinna Vinschen wrote: > On Apr 3 15:12, Johannes Schindelin wrote: > > > On Mon, 3 Apr 2023, Johannes Schindelin wrote: > > > > > On Tue, 28 Mar 2023, Corinna Vinschen wrote: > > > > > > > On Mar 28 10:17, Johannes Schindelin wrote: > > > > > In particular when we cannot figure out a uid for the current user, we > > > > > should still respect the `db_home: env` setting. Such a situation > > > > > occurs > > > > > for example when the domain returned by `LookupAccountSid()` is not > > > > > our > > > > > machine name and at the same time our machine is no domain member: In > > > > > that case, we have nobody to ask for the POSIX offset necessary to > > > > > come > > > > > up with the uid. > > > > > > > > > > It is important that even in such cases, the `HOME` environment > > > > > variable > > > > > can be used to override the home directory, e.g. when Git for Windows > > > > > is > > > > > used by an account that was generated on the fly, e.g. for transient > > > > > use > > > > > in a cloud scenario. > > > > > > > > How does this kind of account look like? I'd like to see the contants > > > > of name, domain, and the SID. Isn't that just an account closely > > > > resembling Micorosft Accounts or AzureAD accounts? Can't we somehow > > > > handle them alike? > > > > > > [...] > > > > > > What I _can_ do is try to recreate the problem (the report said that this > > > happens in a Kudu console of an Azure Web App, see > > > https://github.com/projectkudu/kudu/wiki/Kudu-console) by creating a new > > > Azure Web App and opening that console and run Cygwin within it, which is > > > what I am going to do now. > > > > So here is what is going on: > > > > - The domain is 'IIS APPPOOL' > > There's a domain, so why not pass it to the called function?> Sorry, I was unclear. This domain _is_ used when looking for the uid, but then we run into a code path where the UID cannot be determined (because the domain of the account is not the machine name and the machine is no domain member). The clause in question is here: https://github.com/cygwin/cygwin/blob/cygwin-3.4.6/winsup/cygwin/uinfo.cc#L2303-L2310. The Cygwin runtime then returns -1 as UID. The _subsequent_ call to `getpwuid(-1)` is the one where we need to teach Cygwin to respect `db_home: env`. This is the code path taken by OpenSSH. And that code path only has an `arg.id` to work with (the `type` is `ID_arg`), and that `arg.id` is invalid. There is no domain in that code path that we could possibly pass to the `get_home()` method. > > - The name is the name of the Azure Web App > > > > - The sid is > > 'S-1-5-82-3932326390-3052311582-2886778547-4123178866-1852425102' > > Oh well. These are basically the same thing as 1-5-80 service accounts. > It would be great if we could handle them gracefully instead of > special-case them in a piece of code we just reach because we don't > handle them yet. True, but I don't really understand how they could be handled. > Btw., one easy way out would be if we default to /home/ or > /home/ rather than "/", isn't it? The default does not really matter, as the bug fix is about respecting whatever the user has configured via the `HOME` variable, i.e. it's all about the case when the default needs to be overridden, whatever that default is. Ciao, Johannes
Re: [PATCH v4 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts
Hi Corinna, On Mon, 3 Apr 2023, Corinna Vinschen wrote: > On Apr 3 08:36, Johannes Schindelin wrote: > > Hi Corinna, > > > > On Tue, 28 Mar 2023, Corinna Vinschen wrote: > > > > > On Mar 28 10:17, Johannes Schindelin wrote: > > > > We should not blindly set the home directory of the SYSTEM account (or > > > > of Microsoft accounts) to /home/SYSTEM, especially not when that value > > > ^^ > > > That should probably better be , no? > > > > No, this is the actual name of the home directory when you start > > `Cygwin.bat` using the SYSTEM account. > > I know, but that doesn't match the beginning of your sentence: > > We should not blindly set the home directory of the SYSTEM account > (or of Microsoft accounts) > Ah. I totally focused on the wrong aspect. Will fix the commit message. Ciao, Johannes
Re: [PATCH v4 3/3] Respect `db_home: env` even when no uid can be determined
On Apr 3 15:12, Johannes Schindelin wrote: > Hi Corinna, > > On Mon, 3 Apr 2023, Johannes Schindelin wrote: > > > On Tue, 28 Mar 2023, Corinna Vinschen wrote: > > > > > On Mar 28 10:17, Johannes Schindelin wrote: > > > > In particular when we cannot figure out a uid for the current user, we > > > > should still respect the `db_home: env` setting. Such a situation occurs > > > > for example when the domain returned by `LookupAccountSid()` is not our > > > > machine name and at the same time our machine is no domain member: In > > > > that case, we have nobody to ask for the POSIX offset necessary to come > > > > up with the uid. > > > > > > > > It is important that even in such cases, the `HOME` environment variable > > > > can be used to override the home directory, e.g. when Git for Windows is > > > > used by an account that was generated on the fly, e.g. for transient use > > > > in a cloud scenario. > > > > > > How does this kind of account look like? I'd like to see the contants > > > of name, domain, and the SID. Isn't that just an account closely > > > resembling Micorosft Accounts or AzureAD accounts? Can't we somehow > > > handle them alike? > > > > [...] > > > > What I _can_ do is try to recreate the problem (the report said that this > > happens in a Kudu console of an Azure Web App, see > > https://github.com/projectkudu/kudu/wiki/Kudu-console) by creating a new > > Azure Web App and opening that console and run Cygwin within it, which is > > what I am going to do now. > > So here is what is going on: > > - The domain is 'IIS APPPOOL' There's a domain, so why not pass it to the called function?> > - The name is the name of the Azure Web App > > - The sid is 'S-1-5-82-3932326390-3052311582-2886778547-4123178866-1852425102' Oh well. These are basically the same thing as 1-5-80 service accounts. It would be great if we could handle them gracefully instead of special-case them in a piece of code we just reach because we don't handle them yet. Btw., one easy way out would be if we default to /home/ or /home/ rather than "/", isn't it? Corinna
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest release version available on CPAN: noarch -- perl-DateTime-TimeZone-2.60-1 perl-Exporter-Tiny-1.006002-1 perl-ExtUtils-MakeMaker-7.70-1 perl-Test-Compile-3.1.1-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
Updated: Perl distributions
The following Perl distributions have been updated to their latest release version available on CPAN: noarch -- perl-DateTime-TimeZone-2.60-1 perl-Exporter-Tiny-1.006002-1 perl-ExtUtils-MakeMaker-7.70-1 perl-Test-Compile-3.1.1-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: [PATCH v4 3/3] Respect `db_home: env` even when no uid can be determined
Hi Corinna,
On Mon, 3 Apr 2023, Johannes Schindelin wrote:
> On Tue, 28 Mar 2023, Corinna Vinschen wrote:
>
> > On Mar 28 10:17, Johannes Schindelin wrote:
>
> > > diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
> > > index d493d29b3b..b01bcff5cb 100644
> > > --- a/winsup/cygwin/uinfo.cc
> > > +++ b/winsup/cygwin/uinfo.cc
> > > @@ -883,6 +883,8 @@ fetch_from_path (cyg_ldap *pldap, PUSER_INFO_3 ui,
> > > cygpsid , PCWSTR str,
> > > case L'u':
> > > if (full_qualified)
> > > {
> > > + if (!dom)
> > > + break;
> >
> > No domain? Really?
>
> Yes, I distinctly remember that I had to do that, otherwise the code would
> not work as intended.
Right. This is actually really easy to explain: The new call I introduced
in this very patch passes `NULL` as the `dom` parameter (because this is
in a scenario where we do indeed not have a domain to work with):
if (arg.id == cygheap->user.real_uid)
home = cygheap->pg.get_home ((PUSER_INFO_3) NULL,
cygheap->user.sid(),
NULL, NULL, false);
this is the `dom` parameter
(see
https://github.com/dscho/msys2-runtime/commit/4cd6ae73074f327064b54a08392906dbc140714a#diff-1ffeda03bc188fa732454f52c4932977bc8233d9db4da19ab5acb0c58c7320ccR2188-R2191
for details)
Ciao,
Johannes
Re: [PATCH v4 3/3] Respect `db_home: env` even when no uid can be determined
Hi Corinna,
On Mon, 3 Apr 2023, Johannes Schindelin wrote:
> On Tue, 28 Mar 2023, Corinna Vinschen wrote:
>
> > On Mar 28 10:17, Johannes Schindelin wrote:
> > > In particular when we cannot figure out a uid for the current user, we
> > > should still respect the `db_home: env` setting. Such a situation occurs
> > > for example when the domain returned by `LookupAccountSid()` is not our
> > > machine name and at the same time our machine is no domain member: In
> > > that case, we have nobody to ask for the POSIX offset necessary to come
> > > up with the uid.
> > >
> > > It is important that even in such cases, the `HOME` environment variable
> > > can be used to override the home directory, e.g. when Git for Windows is
> > > used by an account that was generated on the fly, e.g. for transient use
> > > in a cloud scenario.
> >
> > How does this kind of account look like? I'd like to see the contants
> > of name, domain, and the SID. Isn't that just an account closely
> > resembling Micorosft Accounts or AzureAD accounts? Can't we somehow
> > handle them alike?
>
> [...]
>
> What I _can_ do is try to recreate the problem (the report said that this
> happens in a Kudu console of an Azure Web App, see
> https://github.com/projectkudu/kudu/wiki/Kudu-console) by creating a new
> Azure Web App and opening that console and run Cygwin within it, which is
> what I am going to do now.
So here is what is going on:
- The domain is 'IIS APPPOOL'
- The name is the name of the Azure Web App
- The sid is 'S-1-5-82-3932326390-3052311582-2886778547-4123178866-1852425102'
The program I am trying to make work as expected (i.e. to respect the
`db_home: env` line in `/etc/nsswitch.conf` in conjunction with the `HOME`
variable being set to `C:\home`) is `ssh-keygen.exe`: We want it to
default to creating the file `/cygdrive/c/home/.ssh/id_rsa`. But what it
_does_, without this patch, is to default to creating the file
`//.ssh/id_rsa` (which does not make sense because that would refer to a
file share called `id_rsa` on a server whose name is `.ssh`).
Condensed to the bare minimum reproducer, the code boils down to this:
-- snip --
#include
#include
#include
#include
int main(int argc, char **argv)
{
uid_t uid = getuid();
struct passwd *pw = getpwuid(uid);
printf("uid=%u, pw_dir='%s'\n", (unsigned)uid, pw->pw_dir);
return 0;
}
-- snap --
In the Kudu console scenario, this program prints the UID 4294967295
(which is 0x) and _without_ this patch, it prints the `pw_dir` as
being `/`, even if the `HOME` environment variable should override that
for the current user.
_With_ patch 3/3, it prints out the same `uid`, but it does print the
`pw_dir` as `/cygdrive/c/home`.
I will distill the above into a new-and-improved commit message.
Ciao,
Johannes
Re: [PATCH v4 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts
On Apr 3 08:36, Johannes Schindelin wrote: > Hi Corinna, > > On Tue, 28 Mar 2023, Corinna Vinschen wrote: > > > On Mar 28 10:17, Johannes Schindelin wrote: > > > We should not blindly set the home directory of the SYSTEM account (or > > > of Microsoft accounts) to /home/SYSTEM, especially not when that value > > ^^ > > That should probably better be , no? > > No, this is the actual name of the home directory when you start > `Cygwin.bat` using the SYSTEM account. I know, but that doesn't match the beginning of your sentence: We should not blindly set the home directory of the SYSTEM account (or of Microsoft accounts) Corinna
Re: MSG_MORE socket.h flag
On Apr 2 00:19, Chance via Cygwin wrote: > I've used cygwin in the past few years using the MSG_MORE flag when using > some socket functions I have no idea how you did that. MSG_MORE was never actually supported by Cygwin, and the (more or less) equivalent MSG_PARTIAL flag was never exposed into Cygwin user space. > but now it's not defined in cygwin\socket.h and It never was! I checked the history back until the year 2000. > MSG_EOR is using the value of MSG_MORE (0x8000). Above that in the socket.h > file there is a comment /* MSG_EOR is not supported. We use the > MSG_PARTIAL flag here */. I understand this as meaning MSG_EOR now works as > MSG_MORE would and that MSG_EOR is not usable. Just want some clarification > on this. It just means we're using the bit value of MSG_PARTIAL to expose a MSG_EOR flag into user space. It was introduced in 2019 because of POSIX header file compatibility, but it's unsupported and always results in sedn/recv returning EOPNOTSUPP. I'm still puzzled where you got the MSG_MORE definition from, though. 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: [PATCH v4 3/3] Respect `db_home: env` even when no uid can be determined
Hi Corinna,
On Tue, 28 Mar 2023, Corinna Vinschen wrote:
> On Mar 28 10:17, Johannes Schindelin wrote:
> > In particular when we cannot figure out a uid for the current user, we
> > should still respect the `db_home: env` setting. Such a situation occurs
> > for example when the domain returned by `LookupAccountSid()` is not our
> > machine name and at the same time our machine is no domain member: In
> > that case, we have nobody to ask for the POSIX offset necessary to come
> > up with the uid.
> >
> > It is important that even in such cases, the `HOME` environment variable
> > can be used to override the home directory, e.g. when Git for Windows is
> > used by an account that was generated on the fly, e.g. for transient use
> > in a cloud scenario.
>
> How does this kind of account look like? I'd like to see the contants
> of name, domain, and the SID. Isn't that just an account closely
> resembling Micorosft Accounts or AzureAD accounts? Can't we somehow
> handle them alike?
It took a good while to remind me what was going on there. Essentially, I
had to dig up a mail from 2016 that David Ebbo sent me via my work email
(because he was working on Kudu, the Azure shell, where this issue arose).
Sadly, David is no longer a colleague of mine (he seems to work at Google
now), so I cannot pester him about details. Besides, it might be too long
ago to remember details, anyways.
What I _can_ do is try to recreate the problem (the report said that this
happens in a Kudu console of an Azure Web App, see
https://github.com/projectkudu/kudu/wiki/Kudu-console) by creating a new
Azure Web App and opening that console and run Cygwin within it, which is
what I am going to do now.
> > Reported by David Ebbo.
>
> This should be
>
> Reported-By: David Ebbo
Will fix. Naturally, it won't be his Microsoft email address any longer,
but the recent patches I obtained from repositories at
https://github.com/davidebbo/ have a GMail address on record.
> > diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
> > index d493d29b3b..b01bcff5cb 100644
> > --- a/winsup/cygwin/uinfo.cc
> > +++ b/winsup/cygwin/uinfo.cc
> > @@ -883,6 +883,8 @@ fetch_from_path (cyg_ldap *pldap, PUSER_INFO_3 ui,
> > cygpsid , PCWSTR str,
> > case L'u':
> > if (full_qualified)
> > {
> > + if (!dom)
> > + break;
>
> No domain? Really?
Yes, I distinctly remember that I had to do that, otherwise the code would
not work as intended.
Ciao,
Johannes
Re: [PATCH v4 1/3] Allow deriving the current user's home directory via the HOME variable
Hi Corinna & Jon, On Wed, 29 Mar 2023, Corinna Vinschen wrote: > On Mar 28 15:31, Corinna Vinschen wrote: > > On Mar 28 13:34, Jon Turney wrote: > > > On 28/03/2023 11:35, Corinna Vinschen wrote: > > > > Apart from the doc change, the patch is ok now. > > > > > > The preceding text says "Four schema are predefined, two schemata are > > > variable", then we add "env" to both lists? That doesn't make much sense > > > to > > > me. Surely it's just a "predefined schema"? In any case that text should > > > be updated. > > > > Ouch, yeah, I missed that. Thanks for catching! > > I accidentally already pushed this patch, so I took it on me to fix up > the documentation. Thank you for fixing my mistake! 93b05a87c2 (Cygwin: doc: fix description of new "env" schema for /etc/nsswitch.conf, 2023-03-29) looks good to me. Ciao, Johannes
Re: [PATCH v4 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts
Hi Corinna, On Tue, 28 Mar 2023, Corinna Vinschen wrote: > On Mar 28 10:17, Johannes Schindelin wrote: > > We should not blindly set the home directory of the SYSTEM account (or > > of Microsoft accounts) to /home/SYSTEM, especially not when that value > ^^ > That should probably better be , no? No, this is the actual name of the home directory when you start `Cygwin.bat` using the SYSTEM account. To reproduce, I ran `PsExec64.exe -s -i cmd` and then `C:\Cygwin64\Cygwin.bat` in that command prompt (after verifying that `whoami` prints `nt authority\system`). The Bash prompt then says `SYSTEM@`, and `echo $HOME` reports `/home/SYSTEM`. Ciao, Johannes
