Tags: dscho/msys2-runtime
Tags
Cygwin: Adjust CWD magic to accommodate for the latest Windows previews Reportedly a very recent internal build of Windows 11 once again changed the current working directory logic a bit, and Cygwin's "magic" (or: "technologically sufficiently advanced") code needs to be adjusted accordingly. In particular, the following assembly code can be seen: ntdll!RtlpReferenceCurrentDirectory 598 00000001`800c6925 488d0db4cd0f00 lea rcx,[ntdll!FastPebLock (00000001`801c36e0)] 583 00000001`800c692c 4c897810 mov qword ptr [rax+10h],r15 588 00000001`800c6930 0f1140c8 movups xmmword ptr [rax-38h],xmm0 598 00000001`800c6934 e82774f4ff call ntdll!RtlEnterCriticalSection The change necessarily looks a bit different than 4840a56 (Cygwin: Adjust CWD magic to accommodate for the latest Windows previews, 2023-05-22): The needle `\x48\x8d\x0d` is already present, as the first version of the hack after Windows 8.1 was released. In that code, though, the `call` to `RtlEnterCriticalSection` followed the `lea` instruction immediately, but now there are two more instructions separating them. Note: In the long run, we may very well want to follow the insightful suggestion by a helpful Windows kernel engineer who pointed out that it may be less fragile to implement kind of a disassembler that has a better chance to adapt to the ever-changing code of `ntdll!RtlpReferenceCurrentDirectory` by skipping uninteresting instructions such as `mov %rsp,%rax`, `mov %rbx,0x20(%rax)`, `push %rsi` `sub $0x70,%rsp`, etc, and focuses on finding the `lea`, `call ntdll!RtlEnterCriticalSection` and `mov ..., rbx` instructions, much like it was prototyped out for ARM64 at https://gist.github.com/jeremyd2019/aa167df0a0ae422fa6ebaea5b60c80c9 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Submitted-As: https://inbox.sourceware.org/cygwin-patches/6449d894879e33af3e8a4791896d2026f7c3f8bd.1740865389.git.johannes.schindelin@gmx.de
Cygwin: Adjust CWD magic to accommodate for the latest Windows previews Reportedly a very recent internal build of Windows 11 once again changed the current working directory logic a bit, and Cygwin's "magic" (or: "technologically sufficiently advanced") code needs to be adjusted accordingly. In particular, the following assembly code can be seen: ntdll!RtlpReferenceCurrentDirectory 598 00000001`800c6925 488d0db4cd0f00 lea rcx,[ntdll!FastPebLock (00000001`801c36e0)] 583 00000001`800c692c 4c897810 mov qword ptr [rax+10h],r15 588 00000001`800c6930 0f1140c8 movups xmmword ptr [rax-38h],xmm0 598 00000001`800c6934 e82774f4ff call ntdll!RtlEnterCriticalSection The change necessarily looks a bit different than 4840a56 (Cygwin: Adjust CWD magic to accommodate for the latest Windows previews, 2023-05-22): The needle `\x48\x8d\x0d` is already present, as the first version of the hack after Windows 8.1 was released. In that code, though, the `call` to `RtlEnterCriticalSection` followed the `lea` instruction immediately, but now there are two more instructions separating them. Note: In the long run, we may very well want to follow the insightful suggestion by a helpful Windows kernel engineer who pointed out that it may be less fragile to implement kind of a disassembler that has a better chance to adapt to the ever-changing code of `ntdll!RtlpReferenceCurrentDirectory` by skipping uninteresting instructions such as `mov %rsp,%rax`, `mov %rbx,0x20(%rax)`, `push %rsi` `sub $0x70,%rsp`, etc, and focuses on finding the `lea`, `call ntdll!RtlEnterCriticalSection` and `mov ..., rbx` instructions, much like it was prototyped out for ARM64 at https://gist.github.com/jeremyd2019/aa167df0a0ae422fa6ebaea5b60c80c9 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fchmodat/fstatat: fix regression with empty `pathname` In 4b82229 (Cygwin: fix errno values set by readlinkat, 2023-04-18) the code of `readlinkat()` was adjusted to align the `errno` with Linux' behavior. To accommodate for that, the `gen_full_path_at()` function was modified, and the caller was adjusted to expect either `ENOENT` or `ENOTDIR` in the case of an empty `pathname`, not just `ENOENT`. However, `readlinkat()` is not the only caller of that helper function. And while most other callers simply propagate the `errno` produced by `gen_full_path_at()`, two other callers also want to special-case empty `pathnames` much like `readlinkat()`: `fchmodat()` and `fstatat()`. Therefore, these two callers need to be changed to expect `ENOTDIR` in case of an empty `pathname`, too. I noticed this issue when one of my workflows failed consistently while trying to untar an archive containing a symbolic link and claiming this: Cannot change mode to rwxr-xr-x: Not a directory With this here fix, things start working as expected again. Fixes: 4b82229 (Cygwin: fix errno values set by readlinkat, 2023-04-18) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Submitted-As: https://inbox.sourceware.org/cygwin-patches/072b5c57a76c935d79a321526e0c60a1383d22c4.1688484863.git.johannes.schindelin@gmx.de In-Reply-To: https://inbox.sourceware.org/cygwin-patches/c985ab15b28da4fe6f28da4e20236bc0feb484bd.1687898935.git.johannes.schindelin@gmx.de
fchmodat/fstatat: fix regression with empty `pathname` In 4b82229 (Cygwin: fix errno values set by readlinkat, 2023-04-18) the code of `readlinkat()` was adjusted to align the `errno` with Linux' behavior. To accommodate for that, the `gen_full_path_at()` function was modified, and the caller was adjusted to expect either `ENOENT` or `ENOTDIR` in the case of an empty `pathname`, not just `ENOENT`. However, `readlinkat()` is not the only caller of that helper function. And while most other callers simply propagate the `errno` produced by `gen_full_path_at()`, two other callers also want to special-case empty `pathnames` much like `readlinkat()`: `fchmodat()` and `fstatat()`. Therefore, these two callers need to be changed to expect `ENOTDIR` in case of an empty `pathname`, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Submitted-As: https://inbox.sourceware.org/cygwin-patches/c985ab15b28da4fe6f28da4e20236bc0feb484bd.1687898935.git.johannes.schindelin@gmx.de
Support deriving the current user's home directory via HOME
This patch 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).
NOTE! This iteration presents patches 1 & 2 only for completeness' sake
and for backporting, as they have been applied to Cygwin's main branch
already.
Changes since v6:
- Fixed a typo in the last commit's message.
- Support UNC paths as `HOME` values, too. (Tested, works beautifully, I
can now share my WSL home directory with Cygwin.)
Changes since v5:
- Replaced the third patch by a patch that imitates AzureAD account
handling also for IIS APPPPOOL ones.
- Added a fourth patch to fix a bug in the first patch (which
unfortunately was already applied in the buggy form) where _very
early_ calls to `internal_pwsid ()` would result in completely bogus
home directory values.
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 (4):
Allow deriving the current user's home directory via the HOME variable
Respect `db_home` setting even for SYSTEM/Microsoft accounts
uinfo: special-case IIS APPPOOL accounts
Do not rely on `getenv ("HOME")`'s path conversion
winsup/cygwin/local_includes/cygheap.h | 3 +-
winsup/cygwin/uinfo.cc | 170 +++++++++++++++++++++++--
winsup/doc/ntsec.xml | 20 ++-
3 files changed, 181 insertions(+), 12 deletions(-)
Range-diff:
1: e26cae9 = 1: e26cae9 Allow deriving the current user's home directory via the HOME variable
2: 085d4dd = 2: 085d4dd Respect `db_home` setting even for SYSTEM/Microsoft accounts
3: 9b79624 = 3: 9b79624 uinfo: special-case IIS APPPOOL accounts
4: 8ac1548 ! 4: 002d94a Do not rely on `getenv ("HOME")`'s path conversion
@@ Commit message
look at the environment variable `HOME` and use it, if set.
When all of this happens, though, the `pinfo_init ()` function has had no
- change to run yet (and therefore, `environ_init ()`). At this stage,
+ chance to run yet (and therefore, `environ_init ()`). At this stage,
therefore, `getenv ()`'s `findenv_func ()` call still finds `getearly ()`
and we get the _verbatim_ value of `HOME`. That is, the Windows form.
But we need the "POSIX" form.
@@ Commit message
Let's detect when the `HOME` value is still in Windows format in
`fetch_home_env ()`, and convert it in that case.
+ For good measure, interpret this "Windows format" not only to include
+ absolute paths with drive prefixes, but also UNC paths.
+
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
## winsup/cygwin/uinfo.cc ##
@@ winsup/cygwin/uinfo.cc: fetch_home_env (void)
+ {
+ /* In the very early code path of `user_info::initialize ()`, the value
+ of the environment variable `HOME` is still in its Windows form. */
-+ if (isdrive (home))
++ if (isdrive (home) || home[0] == '\\')
+ return (char *) cygwin_create_path (CCP_WIN_A_TO_POSIX, home);
+ return strdup (home);
+ }
base-commit: a9a17f5
Submitted-As: https://inbox.sourceware.org/cygwin-patches/
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1680532960.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1663761086.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/0Lg1Tn-1YnzUw0ScN-00pcgi@mail.gmx.com
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1450375424.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1679991274.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1680620830.git.johannes.schindelin@gmx.de
Adjust CWD magic to accommodate for the latest Windows previews Reportedly Windows 11 build 25*** from Insider changed the current working directory logic a bit, and Cygwin's "magic" (or: "technologically sufficiently advanced") code needs to be adjusted accordingly. This fixes git-for-windows/git#4429 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Submitted-As: https://inbox.sourceware.org/cygwin-patches/
Support deriving the current user's home directory via HOME
This patch 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).
NOTE! This iteration presents patches 1 & 2 only for completeness' sake
and for backporting, as they have been applied to Cygwin's main branch
already.
Changes since v5:
- Replaced the third patch by a patch that imitates AzureAD account
handling also for IIS APPPPOOL ones.
- Added a fourth patch to fix a bug in the first patch (which
unfortunately was already applied in the buggy form) where _very
early_ calls to `internal_pwsid ()` would result in completely bogus
home directory values.
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 (4):
Allow deriving the current user's home directory via the HOME variable
Respect `db_home` setting even for SYSTEM/Microsoft accounts
uinfo: special-case IIS APPPOOL accounts
Do not rely on `getenv ("HOME")`'s path conversion
winsup/cygwin/local_includes/cygheap.h | 3 +-
winsup/cygwin/uinfo.cc | 170 +++++++++++++++++++++++--
winsup/doc/ntsec.xml | 20 ++-
3 files changed, 181 insertions(+), 12 deletions(-)
Range-diff:
1: e26cae9 = 1: e26cae9 Allow deriving the current user's home directory via the HOME variable
2: 085d4dd = 2: 085d4dd Respect `db_home` setting even for SYSTEM/Microsoft accounts
3: cf47afc < -: ---------- Respect `db_home: env` even when no uid can be determined
-: ---------- > 3: 9b79624 uinfo: special-case IIS APPPOOL accounts
-: ---------- > 4: 8ac1548 Do not rely on `getenv ("HOME")`'s path conversion
base-commit: a9a17f5
Submitted-As: https://inbox.sourceware.org/cygwin-patches/cover.1680620830.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1679991274.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1450375424.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/0Lg1Tn-1YnzUw0ScN-00pcgi@mail.gmx.com
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1663761086.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1680532960.git.johannes.schindelin@gmx.de
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).
Sorry for sending out v4 sooooo late...!
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: 7a07499 ! 1: e26cae9 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 <corinna@vinschen.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
## winsup/cygwin/local_includes/cygheap.h ##
@@ winsup/cygwin/uinfo.cc: cygheap_pwdgrp::get_gecos (PUSER_INFO_3 ui, cygpsid &sid
if (ui)
## winsup/doc/ntsec.xml ##
+@@ winsup/doc/ntsec.xml: and on non-AD machines.
+ </para>
+
+ <para>
+-Four schemata are predefined, two schemata are variable. The predefined
++Five schemata are predefined, two schemata are variable. The predefined
+ schemata are the following:
+ </para>
+
@@ winsup/doc/ntsec.xml: schemata are the following:
See <xref linkend="ntsec-mapping-nsswitch-desc"></xref>
for a more detailed description.</listitem>
</varlistentry>
+ <varlistentry>
+ <term><literal>env</literal></term>
-+ <listitem>Derives the home directory of the current user from the
-+ environment variable <literal>HOME</literal> (falling back to
-+ <literal>HOMEDRIVE\HOMEPATH</literal> and
-+ <literal>USERPROFILE</literal>, in that order). This is faster
-+ than the <term><literal>windows</literal></term> schema at the
-+ expense of determining only the current user's home directory
-+ correctly. This schema is skipped for any other account.
-+ </listitem>
++ <listitem>Utilizes the user's environment. This schema is only supported
++ for setting the home directory yet.
++ See <xref linkend="ntsec-mapping-nsswitch-home"></xref> for
++ the description.</listitem>
+ </varlistentry>
</variablelist>
@@ winsup/doc/ntsec.xml: of each schema when used with <literal>db_home:</literal>
+ environment variable <literal>HOME</literal> (falling back to
+ <literal>HOMEDRIVE\HOMEPATH</literal> and
+ <literal>USERPROFILE</literal>, in that order). This is faster
-+ than the <term><literal>windows</literal></term> schema at the
++ than the <literal>windows</literal> schema at the
+ expense of determining only the current user's home directory
+ correctly. This schema is skipped for any other account.
+ </listitem>
2: a70c77d ! 2: 085d4dd 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/<name>`, especially
+ `/etc/nsswitch.conf` defines `db_home: env`, in which case we want to
+ respect the `HOME` variable.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
3: 4cd6ae7 ! 3: cf47afc Respect `db_home: env` even when no uid can be determined
@@ Metadata
## Commit message ##
Respect `db_home: env` even when no uid can be determined
- 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.
+ When we cannot figure out a uid for the current user, we should still
+ respect the `db_home: env` setting.
- 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.
+ 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.
- Reported by David Ebbo.
+ 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 <david.ebbo@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
## winsup/cygwin/uinfo.cc ##
base-commit: a9a17f5
Submitted-As: https://inbox.sourceware.org/cygwin-patches/cover.1680532960.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1663761086.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/0Lg1Tn-1YnzUw0ScN-00pcgi@mail.gmx.com
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1450375424.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1679991274.git.johannes.schindelin@gmx.de
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).
Sorry for sending out v4 sooooo late...!
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 | 22 ++++++++
3 files changed, 91 insertions(+), 4 deletions(-)
Range-diff:
1: 6f8fe89 ! 1: 7a07499 Allow deriving the current user's home directory via the HOME variable
@@ winsup/cygwin/uinfo.cc: fetch_from_path (cyg_ldap *pldap, PUSER_INFO_3 ui, cygps
+static char *
+fetch_home_env (void)
+{
-+ tmp_pathbuf tp;
-+ char *p, *q;
-+ const char *home, *home_drive, *home_path;
++ /* 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;
+
-+ if ((home = getenv ("HOME"))
-+ || ((home_drive = getenv ("HOMEDRIVE"))
-+ && (home_path = getenv ("HOMEPATH"))
+ // concatenate HOMEDRIVE and HOMEPATH
-+ && (home = p = tp.c_get ())
-+ && (q = stpncpy (p, home_drive, NT_MAX_PATH))
-+ && strlcpy (q, home_path, NT_MAX_PATH - (q - p)))
-+ || (home = getenv ("USERPROFILE")))
++ 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;
2: 1b4ee89 = 2: a70c77d Respect `db_home` setting even for SYSTEM/Microsoft accounts
3: 4d90319 ! 3: 4cd6ae7 Respect `db_home: env` even when no uid can be determined
@@ winsup/cygwin/uinfo.cc: fetch_from_path (cyg_ldap *pldap, PUSER_INFO_3 ui, cygps
+ break;
w = wcpncpy (w, dom, we - w);
if (w < we)
- *w++ = cygheap->pg.nss_separator ()[0];
+ *w++ = NSS_SEPARATOR_CHAR;
@@ winsup/cygwin/uinfo.cc: fetch_from_path (cyg_ldap *pldap, PUSER_INFO_3 ui, cygpsid &sid, PCWSTR str,
w = wcpncpy (w, name, we - w);
break;
base-commit: a9a17f5
Submitted-As: https://inbox.sourceware.org/cygwin-patches/cover.1679991274.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1450375424.git.johannes.schindelin@gmx.de
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/0Lg1Tn-1YnzUw0ScN-00pcgi@mail.gmx.com
In-Reply-To: https://inbox.sourceware.org/cygwin-patches/cover.1663761086.git.johannes.schindelin@gmx.de
dumper: avoid linker problem when `libbfd` depends on `libsframe` A recent binutils version introduced `libsframe` and made it a dependency of `libbfd`. This caused a linker problem in the MSYS2 project, and once Cygwin upgrades to that binutils version it would cause the same problems there. Let's preemptively detect the presence of `libsframe` and if detected, link to it in addition to `libbfd`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Submitted-As: https://inbox.sourceware.org/cygwin-patches/50ed771a961112edb5c4b69421d9ad8cecf7a7cb.1675260460.git.johannes.schindelin@gmx.de
PreviousNext