[ANNOUNCEMENT] Updated: tzcode, tzdata 2023c
The following packages have been upgraded in the Cygwin distribution: * tzcode2023c * tzdata2023c The Time Zone Database (often called tz, tzdb, or zoneinfo) contains data that represents the history of local time for many locations around the world, and supports conversion of UTC time to local time at those locations to allow display of those local times. It is updated periodically to reflect changes made by political bodies to summer daylight saving time rules, UTC offsets, and time zone boundaries. The tzcode package provides the tzselect, zdump, and zic utilities. For more information, see the project home page: https://www.iana.org/time-zones For more details on changes, see the announcement or below: https://mm.icann.org/pipermail/tz-announce/2023-March/79.html Release 2023c 2023-03-28 * This release's code and data are identical to 2023a and reverts all changes made in 2023b. Lebanon's spring-forward transition was previously scheduled for March 25/26. Then Lebanon's government announced that the spring-forward transition would be delayed until April 20. Then after the weekend reverted the change. So other than commentary, all changes are reverted, as that appears to be the best of a bad set of short-notice choices for modeling this week's daylight saving chaos in Lebanon. -- 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: tzcode, tzdata 2023c
The following packages have been upgraded in the Cygwin distribution: * tzcode2023c * tzdata2023c The Time Zone Database (often called tz, tzdb, or zoneinfo) contains data that represents the history of local time for many locations around the world, and supports conversion of UTC time to local time at those locations to allow display of those local times. It is updated periodically to reflect changes made by political bodies to summer daylight saving time rules, UTC offsets, and time zone boundaries. The tzcode package provides the tzselect, zdump, and zic utilities. For more information, see the project home page: https://www.iana.org/time-zones For more details on changes, see the announcement or below: https://mm.icann.org/pipermail/tz-announce/2023-March/79.html Release 2023c 2023-03-28 * This release's code and data are identical to 2023a and reverts all changes made in 2023b. Lebanon's spring-forward transition was previously scheduled for March 25/26. Then Lebanon's government announced that the spring-forward transition would be delayed until April 20. Then after the weekend reverted the change. So other than commentary, all changes are reverted, as that appears to be the best of a bad set of short-notice choices for modeling this week's daylight saving chaos in Lebanon.
Re: Setup: How to automate source download for packages already installed?
On Mon, Mar 27, 2023 at 2:55 PM Jon Turney wrote: Sorry, based on the previous discussion at [1] this seems to be broken > at the moment, due to '-x' being broken. > > [1] https://cygwin.com/pipermail/cygwin/2023-February/252994.html > > If you really need this, please try old setup versions from [2]. If you > discover which version it got broken in, and/or work out how to fix it, > please let us know. > > [2] https://cygwin.com/setup/ > Completed testing. The last version where: --include-source --local-package-dir "path" -x "package[,...]" -P "package[,...]" ...worked was 2.918. It does not work in 2.919 and later. Bill -- 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 1/3] Allow deriving the current user's home directory via the HOME variable
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! Corinna
Re: [PATCH v4 1/3] Allow deriving the current user's home directory via the HOME variable
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. On Mar 28 10:17, Johannes Schindelin wrote: diff --git a/winsup/doc/ntsec.xml b/winsup/doc/ntsec.xml index c6871ecf05..1678ff6575 100644 --- a/winsup/doc/ntsec.xml +++ b/winsup/doc/ntsec.xml @@ -1203,6 +1203,17 @@ 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. + + I'd rephrase that a bit here. This is the description of the scheme itself, so this should be something along the lines of "utilizes the current environment ..." and "Right now only valid for db_home, see xref linkend="ntsec-mapping-nsswitch-home"... However, there's something strange going on, see below. @@ -1335,6 +1346,17 @@ of each schema when used with db_home: See for a 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 I think drop wrapping in here should fix the error below. It's not valid docbook here. + expense of determining only the current user's home directory + correctly. This schema is skipped for any other account. + + @ad_attribute AD only: The user's home directory is set to the path given There's something wrong here. Building the docs, I get these new error messages: docbook2texi://sect4[@id='ntsec-mapping-nsswitch-passwd']/variablelist[1]/varlistentry[5]/listitem/term: element not matched by any template docbook2texi://sect4[@id='ntsec-mapping-nsswitch-home']/variablelist/varlistentry[5]/listitem/term: element not matched by any template Element term in namespace '' encountered in listitem, but no template matches. Element term in namespace '' encountered in listitem, but no template matches. Element term in namespace '' encountered in listitem, but no template matches. Element term in namespace '' encountered in listitem, but no template matches. No template matches term in listitem. No template matches term in listitem. It looks like this has something to do with the expression? Jon, do you have an idea?
Re: [PATCH v4 1/3] Allow deriving the current user's home directory via the HOME variable
Apart from the doc change, the patch is ok now. On Mar 28 10:17, Johannes Schindelin wrote: > diff --git a/winsup/doc/ntsec.xml b/winsup/doc/ntsec.xml > index c6871ecf05..1678ff6575 100644 > --- a/winsup/doc/ntsec.xml > +++ b/winsup/doc/ntsec.xml > @@ -1203,6 +1203,17 @@ 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. > + > + > I'd rephrase that a bit here. This is the description of the scheme itself, so this should be something along the lines of "utilizes the current environment ..." and "Right now only valid for db_home, see xref linkend="ntsec-mapping-nsswitch-home"... However, there's something strange going on, see below. > > @@ -1335,6 +1346,17 @@ of each schema when used with > db_home: > See > for a 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. > + > + > > @ad_attribute > AD only: The user's home directory is set to the path given There's something wrong here. Building the docs, I get these new error messages: docbook2texi://sect4[@id='ntsec-mapping-nsswitch-passwd']/variablelist[1]/varlistentry[5]/listitem/term: element not matched by any template docbook2texi://sect4[@id='ntsec-mapping-nsswitch-home']/variablelist/varlistentry[5]/listitem/term: element not matched by any template Element term in namespace '' encountered in listitem, but no template matches. Element term in namespace '' encountered in listitem, but no template matches. Element term in namespace '' encountered in listitem, but no template matches. Element term in namespace '' encountered in listitem, but no template matches. No template matches term in listitem. No template matches term in listitem. It looks like this has something to do with the expression? Jon, do you have an idea? Corinna
Re: [PATCH v4 3/3] Respect `db_home: env` even when no uid can be determined
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?
> Reported by David Ebbo.
This should be
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;
No domain? Really?
Corinna
Re: [PATCH v4 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts
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?
> disagrees with what is configured via the `db_home` line in the
> `/etc/nsswitch.conf` file.
>
> 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
>
Re: [PATCH 0/2] Provide virtual /dev/fd and /dev/{stdin, stdout, stderr} symlinks
Hi Brian, On Fri, 25 Feb 2022, Brian Inglis wrote: > On 2022-02-21 06:36, Johannes Schindelin wrote: > > These symbolic links are crucial e.g. to support process substitution > > (Bash's > > very nice `<(SOME-COMMAND)` feature). > > > > For various reasons, it is a bit cumbersome (or impossible) to generate > > these > > symbolic links in all circumstances where Git for Windows wants to use its > > close fork of the Cygwin runtime. > > > > Therefore, let's just handle these symbolic links as implicit, virtual ones. > > > > If there is appetite for it, I wonder whether we should do something similar > > for `/dev/shm` and `/dev/mqueue`? Are these even still used in Cygwin? > > Looks like that would make sense, as Cygwin appears to create all of those > only on first startup (and probably rechecks if they need created every > startup) e.g. > > Cygwin-32 $ ls -Fglot /dev/ | tail -6 > lrwxrwxrwx 1 13 Apr 29 2012 fd -> /proc/self/fd/ > lrwxrwxrwx 1 15 Apr 29 2012 stderr -> /proc/self/fd/2 > lrwxrwxrwx 1 15 Apr 29 2012 stdout -> /proc/self/fd/1| > lrwxrwxrwx 1 15 Apr 29 2012 stdin -> /proc/self/fd/0 > drwxr-xr-x+ 10 Apr 29 2012 mqueue/ > drwxr-xr-x+ 10 Apr 29 2012 shm/ > > Cygwin-64 $ ls -Fglot /dev/ | tail -6 > drwxrwxrwt+ 10 Dec 2 2017 shm/ > lrwxrwxrwx 1 13 May 14 2013 fd -> /proc/self/fd/ > lrwxrwxrwx 1 15 May 14 2013 stderr -> /proc/self/fd/2 > lrwxrwxrwx 1 15 May 14 2013 stdout -> /proc/self/fd/1| > lrwxrwxrwx 1 15 May 14 2013 stdin -> /proc/self/fd/0 > drwxrwxrwt+ 10 May 14 2013 mqueue/ > > so they would all get 2006-12-01 00:00:00+ birth time. > > [Looks like I ran something using shm in 2017!] Thank you for that additional context! As Corinna pointed out, the directories currently need to exist on disk (so that mmap()able files can be created in them), though, and even if there _might_ be a way to avoid this (which would be good, in Git for Windows' context, where the runtime's pseudo root directory is inside `C:\Program Files`, i.e. read-only) it looks like a bit too much of a challenge for me to take on, at least for now. Ciao, Johannes
Re: [PATCH 0/2] Provide virtual /dev/fd and /dev/{stdin, stdout, stderr} symlinks
Hi Corinna, On Mon, 28 Feb 2022, Corinna Vinschen wrote: > On Feb 28 10:24, Corinna Vinschen wrote: > > On Feb 25 16:46, Johannes Schindelin wrote: > > > On Tue, 22 Feb 2022, Corinna Vinschen wrote: > > > > On Feb 21 14:36, Johannes Schindelin wrote: > > > > > If there is appetite for it, I wonder whether we should do something > > > > > similar > > > > > for `/dev/shm` and `/dev/mqueue`? Are these even still used in Cygwin? > > > > > > > > "still used"? These are the dirs to store POSIX semaphors, message > > > > queues and shared mem objects. > > > > > > Okay. I guess we do not really use them in Git for Windows ;-) > > > > Probably not. I'm not aware that git uses POSIX IPC objects. > > > > > > These have to be real on-disk dirs. > > > > > > Could I ask you to help me understand why? Do they have to be writable? Or > > > do the things that are written into them have to be persisted between > > > Cygwin sessions? > > > > Cygwin uses ordinary on-disk files to emulate the objects, and > > they have to persist over process exits. Unfortunately I don't > > see any other way to create persistent objects from user space. > > Btw., you don't have to create those dirs. Only if you actually use > POSIX IPC calls, the directories are required. > > In fact, the IPC objects are just mmaps (message queues, shared mem > objects), or the file is just used to store the values after closing > the object (semaphores). Okay, I _think_ I understand the issue better now. Thank you for indulging me! > With "persistent" I mean, "DLL lifetime persistent". It's not required > that the objects are persistent until system shutdown, as it is now with > file-based objects. > > It would be sufficient if the objects persist until the last Cygwin > process of a Cygwin process tree exits. I'm open to ideas, but they > shouldn't further slow down the startup of a Cygwin process tree. From my limited understanding, that _sounds_ as if a shared object might be enough (similar to the shared parent directory that `winsup/cygwin/shared.cc` is all about). If this sounds like a viable approach, I'll put it into my ever-growing backlog ;-) Ciao, Johannes
Re: [PATCH] Cygwin: Improve FAQ on early breakpoint for ASLR
Hi Jon,
On Wed, 14 Dec 2022, Jon Turney wrote:
> On 11/12/2022 14:45, Johannes Schindelin wrote:
> > On December 11, 2022 2:54:02 PM GMT+01:00, Jon Turney
> > wrote:
> > > On 05/12/2022 15:23, Johannes Schindelin wrote:
> > > > On Mon, 28 Nov 2022, Corinna Vinschen wrote:
> > > > > On Nov 28 13:00, Jon Turney wrote:
> > > > > > On 15/11/2022 10:46, Corinna Vinschen wrote:
> > > > > > >
> > > > > > > It would be great if we could get used to using the same syntax as
> > > > > > > the
> > > > > > > Linux kernel project to document stuff. I'm trying to follow
> > > > > > > their lead
> > > > > > > for a while. For fixes to former commits, it looks like this in
> > > > > > > the
> > > > > > > kernel, at the end of the commit message:
> > > > > > >
> > > > > > > Fixes: 123456789012 ("title of commit 123456789012")
> > > > > > >
> > > > > > > Yeah, core.abbrev is 12 digits. I'm using this setting for quite
> > > > > > > some
> > > > > > > time locally.
> > > > > >
> > > > > > Sounds good. Is there some script to automate generating this kind
> > > > > > of
> > > > > > comment from a commit-id?
> > > > >
> > > > > I don't think so, at least I don't see anything like that in git
> > > > > docs...
> > > >
> > > > It's note _quite_ what you asked for, but `git show --pretty=reference
> > > > -s
> > > > ` (https://git-scm.com/docs/git-show#_pretty_formats) gives you
> > > > _almost_ what you are looking for.
> > > >
> > > > But you can always call `git show -s --format='%h ("%s")' `, and
> > > > even configure an alias for this:
> > > >
> > > > git config --global alias.pretty-print-commit \
> > > > "-c core.abbrev=12 show -s --format='%h (\"%s\")'"
> > > >
> > > Thanks!
> > >
> > > I added '-c core.pager=', but this is what I was looking for, to save a
> > > bit of copying and pasting and editing.
> > >
> >
> > Better use `git -P`, then... (see
> > https://git-scm.com/docs/git#Documentation/git.txt--P for full details)
> >
>
> I started off with that, but that fails when used with:
>
> fatal: alias 'pretty-print-commit' changes environment variables.
> You can use '!git' in the alias to do this
>
> ... which I'm sure tells me the right way to write this :)
My apologies for leading you on this windy path through Git's obscure and
intricate internals.
The problem is that the `-P` option claims to change the environment (see
https://github.com/git/git/blob/v2.40.0/git.c#L176-L179), and aliases are
not allowed to do that.
You _can_ work around that by using `!git -P [...]`, i.e. by forcing a
shell to be spawned that then spawns `git`. But that is wasteful,
especially given the performance characteristics of spawning processes in
Cygwin.
Therefore, your `-c core.pager=` solution is much preferable to my
suggestion to use `-P`.
Ciao,
Johannes
How to remove "Priveleged Server" as default UAC prompt?
I installed the Cron daemon running under the cyg_server account, and now whenever Windows 10 gives me a UAC prompt it defaults to asking for the password for "privileged server" and I have to manually click to change it to my PIN entry every time. This is extremely annoying and slows down what would otherwise be very fast interactions. Is there a way to revert this behavior without uninstalling Cron and/or the cyg_server account? And if I run Cron under my own username (I have admin rights, but UAC is enabled) will it be able to automate actions that require admin privileges? -- 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 v2 1/2] Allow deriving the current user's home directory via the HOME variable
Hi Corinna,
On Mon, 21 Nov 2022, Corinna Vinschen wrote:
> On Nov 18 09:18, Johannes Schindelin wrote:
> > Hi Corinna,
> >
> > On Thu, 10 Nov 2022, Corinna Vinschen wrote:
> > > On Nov 10 16:16, Johannes Schindelin wrote:
> > > > With this context in mind, I would like to ask to integrate the patch
> > > > as-is, including the HOMEDRIVE/HOMEPATH and USERPROFILE fall-backs.
> > >
> > > Can't do that, sorry. Two replies before I sent a necessary change,
> > > which needs inclusion first.
> >
> > I am a bit confused. Do you need anything from me to move this along, i.e.
> > are those two replies you mention some emails I failed to address yet?
>
> I didn't mean two different replies, but my second-last reply before
> that one, i. e.
> https://cygwin.com/pipermail/cygwin-patches/2022q4/012025.html
>
> Sorry if that wasn't clear. Basically your handling of $HOME was
> wrong and I suggested a fix.
Sorry about being so thick! I thought I had done exactly what you asked
for, but had missed that `getenv("HOME")` already converts the path to a
Unix-y form but the same is untrue when getting `HOMEDRIVE`, `HOMEPATH`
and `USERPROFILE`.
I took the opportunity to unclutter the `fetch_home_env()` function and
document it, to improve the readability by strides.
Ciao,
Johannes
[PATCH v4 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/SYSTEM, especially not when that value
disagrees with what is configured via the `db_home` line in the
`/etc/nsswitch.conf` file.
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 v4 3/3] 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.
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.
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 v4 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`.
Signed-off-by: Johannes Schindelin
---
winsup/cygwin/local_includes/cygheap.h | 3 +-
winsup/cygwin/uinfo.cc | 51 ++
winsup/doc/ntsec.xml | 22 +++
3 files changed, 75 insertions(+), 1 deletion(-)
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 @@ cygheap_pwdgrp::get_shell (PUSER_INFO_3 ui, cygpsid ,
[PATCH v4 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).
Sorry for sending out v4 so 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: 6f8fe89d9d ! 1: 7a074997ea 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: 1b4ee89aa7 = 2: a70c77dc8f Respect `db_home` setting even for
SYSTEM/Microsoft accounts
3: 4d90319e44 ! 3: 4cd6ae7307 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 , PCWSTR str,
w = wcpncpy (w, name, we - w);
break;
base-commit: a9a17f5fe51498b182d4a11ac48207b8c7ffe8ec
Published-As:
https://github.com/dscho/msys2-runtime/releases/tag/home-env-cygwin-v4
Fetch-It-Via: git fetch https://github.com/dscho/msys2-runtime
home-env-cygwin-v4
--
2.40.0.windows.1
