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