public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH] Allow overriding the home directory via the HOME variable
Date: Fri, 23 Oct 2015 09:10:00 -0000	[thread overview]
Message-ID: <20151023091018.GE5319@calimero.vinschen.de> (raw)
In-Reply-To: <alpine.DEB.1.00.1510221731250.31610@s15462909.onlinehome-server.info>

[-- Attachment #1: Type: text/plain, Size: 4272 bytes --]

On Oct 22 17:38, Johannes Schindelin wrote:
> Hi Corinna,
> 
> On Wed, 21 Oct 2015, Corinna Vinschen wrote:
> 
> > On Sep 16 15:06, Johannes Schindelin wrote:
> > > 	* uinfo.cc (cygheap_pwdgrp::get_home): Offer an option in
> > > 	nsswitch.conf that let's the environment variable HOME (or
> > > 	HOMEDRIVE & HOMEPATH, or USERPROFILE) define the home
> > > 	directory.
> > > 
> > > 	* ntsec.xml: Document the `env` schema.
> > > 
> > > Detailed comments:
> > > 
> > > In the context of Git for Windows, 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.
> > 
> > -v, please.  Which applications can't handle that?  Why do we have to
> > care?
> 
> Oh, the first one that comes to mind is `cmd.exe`. You cannot start
> `cmd.exe` with a UNC working directory without getting complaints.

Sure, but then again, why do we have to care?  Didn't you say GfW is
using bash?

> > > The established technique is to allow setting the user's home directory
> > > via the environment variables mentioned above.  This has the additional
> > > advantage that it is much faster than querying the Windows user database.
> > 
> > But it's wrong.  We discussed this a couple of times on the Cygwin ML.
> > The underlying functionality generically implements the passwd entries.
> > Your "env" setting will return the same $HOME setting in the pw_dir
> > field for every user account.
> 
> No, it will not, because most users are not administrators. So they can
> only set environment variables for themselves.

You're looking at the problem from the wrong direction.  Consider how
the mechanism works.  The setting in /etc/nsswitch.conf configures how
the passwd/group entries for all accounts are created.  Your "env"
setting fetches the environment of the *current* user and generates
the passwd entry for *all* user accounts from it.  Here's what happens:

  $ echo $USER
  corinna
  $ echo $HOME
  /home/corinna
  $ getent passwd $USER
  corinna:*:1049577:1049701:U-VINSCHEN\corinna,S-1-5-21-913048732-1697188782-3448811101-1001:/home/corinna:/bin/tcsh
  $ getent passwd Guest
  Guest:*:1049077:1049090:U-VINSCHEN\Guest,S-1-5-21-2913048732-1697188782-3448811101-501:/home/corinna:/bin/bash
  $ getent passwd Administrator
  Administrator:*:1049076:1049089:U-VINSCHEN\Administrator,S-1-5-21-2913048732-1697188782-3448811101-500:/home/corinna:/bin/bash
  [...]

This is plain wrong.  You can't seriously provide a mechanism which
fetches data from the current user to generate the output for all users
from there.

> In most cases, `HOME` will not even be defined, but `HOMEDRIVE` and
> `HOMEPATH` will, and they will be correct.

That's not the point.

> > All user accounts will have the same home dir as your current user.  And
> > the value is unreliable, too.  If another user logs in, all accounts
> > will have another $HOME, the one from the now logged in user.  This is
> > so wrong and potentially dangerous that I don't think this belongs into
> > Cygwin, sorry.
> 
> I ask you to reconsider.

I did, but the result is the same.  As is, the patch is not acceptable.

Here's what you *could* do:  Create a patch which fetches the pw_home
info from the current user environment for the current user only.  For
all other accounts, the info must be taken from elsewhere, one of the
other methods.  E.g., the env setting only affects the current user
passwd entry, not any other.  For all other accounts, the env method
provides no result, thus falling back to the next method in the row.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-10-23  9:10 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16 13:06 Johannes Schindelin
2015-10-21 18:32 ` Corinna Vinschen
2015-10-22 15:38   ` Johannes Schindelin
2015-10-23  9:10     ` Corinna Vinschen [this message]
2015-10-23  9:41       ` Corinna Vinschen
2015-10-23 12:00         ` Johannes Schindelin
2015-12-17 18:05 ` [PATCH v2 0/2] Support deriving the current user's home directory via HOME Johannes Schindelin
2015-12-17 18:05   ` [PATCH v2 1/2] Allow deriving the current user's home directory via the HOME variable Johannes Schindelin
2015-12-17 20:20     ` Corinna Vinschen
2022-09-21 11:58       ` Johannes Schindelin
2022-10-18 17:02         ` Corinna Vinschen
2022-10-23 21:04           ` Johannes Schindelin
2022-10-24 11:37             ` Corinna Vinschen
2022-11-10 15:16               ` Johannes Schindelin
2022-11-10 15:22                 ` Corinna Vinschen
2022-11-18  8:18                   ` Johannes Schindelin
2022-11-21 11:41                     ` Corinna Vinschen
2023-03-28  8:21                       ` Johannes Schindelin
2015-12-17 18:05   ` [PATCH v2 2/2] Respect `db_home` setting even for the SYSTEM account Johannes Schindelin
2015-12-17 20:49     ` Corinna Vinschen
2015-12-17 21:02       ` Corinna Vinschen
2022-09-21 12:00       ` Johannes Schindelin
2022-09-21 11:51   ` [PATCH v3 0/3] Support deriving the current user's home directory via HOME Johannes Schindelin
2022-09-21 11:51     ` [PATCH v3 1/3] Allow deriving the current user's home directory via the HOME variable Johannes Schindelin
2022-09-21 11:52     ` [PATCH v3 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts Johannes Schindelin
2022-09-21 11:52     ` [PATCH v3 3/3] Respect `db_home: env` even when no uid can be determined Johannes Schindelin
2023-03-28  8:17     ` [PATCH v4 0/3] Support deriving the current user's home directory via HOME Johannes Schindelin
2023-03-28  8:17       ` [PATCH v4 1/3] Allow deriving the current user's home directory via the HOME variable Johannes Schindelin
2023-03-28 10:35         ` Corinna Vinschen
2023-03-28 12:34           ` Jon Turney
2023-03-28 13:31             ` Corinna Vinschen
2023-03-29  8:36               ` Corinna Vinschen
2023-04-03  6:39                 ` Johannes Schindelin
2023-03-28  8:17       ` [PATCH v4 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts Johannes Schindelin
2023-03-28 10:16         ` Corinna Vinschen
2023-04-03  6:36           ` Johannes Schindelin
2023-04-03 10:59             ` Corinna Vinschen
2023-04-03 13:32               ` Johannes Schindelin
2023-03-28  8:17       ` [PATCH v4 3/3] Respect `db_home: env` even when no uid can be determined Johannes Schindelin
2023-03-28 10:17         ` Corinna Vinschen
2023-04-03  6:45           ` Johannes Schindelin
2023-04-03 13:12             ` Johannes Schindelin
2023-04-03 13:29               ` Corinna Vinschen
2023-04-03 13:57                 ` Johannes Schindelin
2023-04-03 19:23                   ` Corinna Vinschen
2023-04-04 15:11                     ` Johannes Schindelin
2023-04-03 13:19             ` Johannes Schindelin
2023-04-03 14:44       ` [PATCH v5 0/3] Support deriving the current user's home directory via HOME Johannes Schindelin
2023-04-03 14:44         ` [PATCH v5 1/3] Allow deriving the current user's home directory via the HOME variable Johannes Schindelin
2023-04-03 18:36           ` Corinna Vinschen
2023-04-04 15:12             ` Johannes Schindelin
2023-04-03 14:45         ` [PATCH v5 2/3] Respect `db_home` setting even for SYSTEM/Microsoft accounts Johannes Schindelin
2023-04-03 18:37           ` Corinna Vinschen
2023-04-04 15:12             ` Johannes Schindelin
2023-04-03 14:45         ` [PATCH v5 3/3] Respect `db_home: env` even when no uid can be determined Johannes Schindelin
2023-04-04 15:07         ` [PATCH v6 0/4] Support deriving the current user's home directory via HOME Johannes Schindelin
2023-04-04 15:07           ` [PATCH v6 1/4] Allow deriving the current user's home directory via the HOME variable Johannes Schindelin
2023-04-04 15:07           ` [PATCH v6 2/4] Respect `db_home` setting even for SYSTEM/Microsoft accounts Johannes Schindelin
2023-04-04 15:07           ` [PATCH v6 3/4] uinfo: special-case IIS APPPOOL accounts Johannes Schindelin
2023-04-04 15:07           ` [PATCH v6 4/4] Do not rely on `getenv ("HOME")`'s path conversion Johannes Schindelin
2023-04-06  8:37             ` Corinna Vinschen
2023-04-06  9:54               ` Johannes Schindelin
2023-04-06 10:28                 ` Corinna Vinschen
2023-05-22 11:12           ` [PATCH v7 0/4] Support deriving the current user's home directory via HOME Johannes Schindelin
2023-05-22 11:12             ` [PATCH v7 1/4] Allow deriving the current user's home directory via the HOME variable Johannes Schindelin
2023-05-22 11:12             ` [PATCH v7 2/4] Respect `db_home` setting even for SYSTEM/Microsoft accounts Johannes Schindelin
2023-05-22 11:12             ` [PATCH v7 3/4] uinfo: special-case IIS APPPOOL accounts Johannes Schindelin
2023-05-22 11:13             ` [PATCH v7 4/4] Do not rely on `getenv ("HOME")`'s path conversion Johannes Schindelin
2023-06-06 13:33             ` [PATCH v7 0/4] Support deriving the current user's home directory via HOME Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151023091018.GE5319@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-patches@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).