RFC: 1.7.33 problem with user's home directory

RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

Hi,


after a long discussion in RL today, I came to the conclusion that
there's a major problem in the current handling of the user's home
directory in AD environments in the new user account code when not using
/etc/passwd files.

Here's how it works and how it's documented in the preliminary
documentation at
https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo

- If your account is an AD account, the home directory is taken from the
  RFC 2307 entry unixHomeDirectory.

- Otherwise, if these values are empty or don't exist, your fallback
  home directory is /home/$USER (without domain prefix).

As you may have noticed, there's nothing in there taking the Windows
home directory into account.  It's indeed not used at all by the new
code.

Up to Cygwin 1.7.32, mkpasswd (but not with -u) generated the Cygwin
home directory by converting the SAM/AD home folder entry to POSIX
style, if it's non-empty.  Fallback is /home/$USER.

When I implemented the new scheme I thought it a good idea to decouple
the Cygwin home dir from the Windows home dir.  However, in the today's
discussion the following two arguments came up:

- If you're using the Windows home folder setting to maintain file
  server based home directories, you typically want that these
  directories are used for Cygwin stuff as well (central administration,
  central backup).
  Having to maintain the home directories twice, once in the
  homeDirectory, once in the unixHomeDirectory entry is quite a hassle,
  especially given that unixHomeDirectory does not support variable
  substitution (e.g. "/home/%USERNAME%" won't work).

- If you're already using AD as NIS server, unixHomeDirectory is already
  used for UNIX machines.  Trying to align the unixHomeDirectory for
  Cygwin to homeDirectory for all the rest of Windows will potentially
  become impossible then.

These arguments are quite serious and it questions the "good idea" part
of this change a lot.

What do you think?

Shall the "db" entries utilize the Windows home folder if it exits(*)
and drop using the unixHomeDirectory?  It seems inevitable...


Corinna


(*) This would automatically work for SAM accounts as well because SAM
    provides the same Windows home folder entry.


-- 
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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Achim Gratz]

Corinna Vinschen writes:
> - If your account is an AD account, the home directory is taken from the
>   RFC 2307 entry unixHomeDirectory.

This isn't set yet in our domain, but there's another AD just for the
UNIX accounts (I haven't looked at how that one is structured yet).
There's talk about maybe unifying these two AD in the future, but I have
no idea how that would work.

> - Otherwise, if these values are empty or don't exist, your fallback
>   home directory is /home/$USER (without domain prefix).
>
> As you may have noticed, there's nothing in there taking the Windows
> home directory into account.  It's indeed not used at all by the new
> code.

I think that is generally the right idea, since mixing all the .-files
into the normal Windows home directory results in a mess, especially
when there are Windows programs ported from Unix that use the same
scheme for themselves.  What I'm doing right now is to create an
/etc/fstab.d/$USER that mounts a subdirectory of the Windows $HOME
(always a network drive for normal domain users) when I set up a new
users' machine or login on a server.  I also mount the actual Windows
home back under ~/winhome.

> Shall the "db" entries utilize the Windows home folder if it exits(*)
> and drop using the unixHomeDirectory?  It seems inevitable...

That would cause serious problems for me I think.  Keeping the home
directory pinned to /home/$USER and automounting this based on some rule
involving either or both of those entries seems a better idea in the
long run.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 10 22:18, Achim Gratz wrote:
> Corinna Vinschen writes:
> > - If your account is an AD account, the home directory is taken from the
> >   RFC 2307 entry unixHomeDirectory.
> 
> This isn't set yet in our domain, but there's another AD just for the
> UNIX accounts (I haven't looked at how that one is structured yet).
> There's talk about maybe unifying these two AD in the future, but I have
> no idea how that would work.

If you're doing that at one point...

> > - Otherwise, if these values are empty or don't exist, your fallback
> >   home directory is /home/$USER (without domain prefix).
> >
> > As you may have noticed, there's nothing in there taking the Windows
> > home directory into account.  It's indeed not used at all by the new
> > code.
> 
> I think that is generally the right idea, since mixing all the .-files
> into the normal Windows home directory results in a mess, especially
> when there are Windows programs ported from Unix that use the same
> scheme for themselves.  What I'm doing right now is to create an
> /etc/fstab.d/$USER that mounts a subdirectory of the Windows $HOME
> (always a network drive for normal domain users) when I set up a new
> users' machine or login on a server.  I also mount the actual Windows
> home back under ~/winhome.
> 
> > Shall the "db" entries utilize the Windows home folder if it exits(*)
> > and drop using the unixHomeDirectory?  It seems inevitable...
> 
> That would cause serious problems for me I think.  Keeping the home
> directory pinned to /home/$USER and automounting this based on some rule
> involving either or both of those entries seems a better idea in the
> long run.

...it might give you similar trouble as you outline above.  As soon as
the RFC 2307 posixAccount/posixGroup scheme is utilized for Unix
machines, Cygwin's usage of unixHomeDirectory would potentially break
your modus operandi...


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > This isn't set yet in our domain, but there's another AD just for the
> > UNIX accounts (I haven't looked at how that one is structured yet).
> > There's talk about maybe unifying these two AD in the future, but I have
> > no idea how that would work.
> 
> If you're doing that at one point...
> ...it might give you similar trouble as you outline above.  As soon as
> the RFC 2307 posixAccount/posixGroup scheme is utilized for Unix
> machines, Cygwin's usage of unixHomeDirectory would potentially break
> your modus operandi...

Right, that's why I think that Cygwin should always have the users home in
/home/$USER and mount that based on some rule that the administrator can
specify.


Regards,
Achim


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

> Up to Cygwin 1.7.32, mkpasswd (but not with -u) generated the Cygwin
> home directory by converting the SAM/AD home folder entry to POSIX
> style, if it's non-empty.  Fallback is /home/$USER.

> When I implemented the new scheme I thought it a good idea to decouple
> the Cygwin home dir from the Windows home dir.  However, in the today's
> discussion the following two arguments came up:

> - If you're using the Windows home folder setting to maintain file
>   server based home directories, you typically want that these
>   directories are used for Cygwin stuff as well (central administration,
>   central backup).
>   Having to maintain the home directories twice, once in the
>   homeDirectory, once in the unixHomeDirectory entry is quite a hassle,
>   especially given that unixHomeDirectory does not support variable
>   substitution (e.g. "/home/%USERNAME%" won't work).

> - If you're already using AD as NIS server, unixHomeDirectory is already
>   used for UNIX machines.  Trying to align the unixHomeDirectory for
>   Cygwin to homeDirectory for all the rest of Windows will potentially
>   become impossible then.

> These arguments are quite serious and it questions the "good idea" part
> of this change a lot.

> What do you think?

> Shall the "db" entries utilize the Windows home folder if it exits(*)
> and drop using the unixHomeDirectory?  It seems inevitable...

All I can say about this issue is… I told you.
I see literally zero reason to maintain separate, cygwin-specific "home"
directory.
If you want a separate environment to play with, VirtualBox is there to
accommodate your wildest dreams. (Though, Oracle is trying hard to turn people
away from using VB since 4.3.13+)


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 11.11.2014, <03:37>

Sorry for my terrible english...

Re: RFC: 1.7.33 problem with user's home directory

[Andrew DeFaria]

On 11/10/2014 4:45 PM, Andrey Repin wrote:

> I see literally zero reason to maintain separate, cygwin-specific "home"
> directory.

My reason to have a separate, cygwin-specific "home" directory is to 
have one that is shared between Cygwin and Linux. Windows define home 
directories rarely are shared....
-- 
Andrew DeFaria
http://defaria.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Andrew DeFaria!

> On 11/10/2014 4:45 PM, Andrey Repin wrote:

>> I see literally zero reason to maintain separate, cygwin-specific "home"
>> directory.

> My reason to have a separate, cygwin-specific "home" directory is to 
> have one that is shared between Cygwin and Linux.

I do that without creating cygwin-specific /home.

> Windows define home directories rarely are shared....

So do Linux...


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 11.11.2014, <09:26>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Frank Fesevur]

2014-11-11 1:45 GMT+01:00 Andrey Repin:
> I see literally zero reason to maintain separate, cygwin-specific "home"
> directory.

I think I have to disagree with you. When mixing MSYS, msysGit and
Cygwin in the same home directory the dot-files can become a problem.
Especially when it comes to line ending in those files and the line
ending setting in .gitconfig.

Regards,
Frank

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Frank Fesevur!

>> I see literally zero reason to maintain separate, cygwin-specific "home"
>> directory.

> I think I have to disagree with you. When mixing MSYS, msysGit and
> Cygwin in the same home directory the dot-files can become a problem.
> Especially when it comes to line ending in those files and the line
> ending setting in .gitconfig.

I think, the number of people mixing these things is lower than number of
people using Cygwin with roaming profiles.
And they know what they are doing, by definition.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 11.11.2014, <18:05>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Jeffrey Altman]

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

On 11/10/2014 3:52 PM, Corinna Vinschen wrote:
> Hi,
> 
> 
> after a long discussion in RL today, I came to the conclusion that
> there's a major problem in the current handling of the user's home
> directory in AD environments in the new user account code when not using
> /etc/passwd files.


My personal preference would be for the Cygwin Home directory to be
created under

  %HOMEPATH%\AppData\Roaming\Cygwin

That way the home directory is isolated from native windows applications
that might use the same file names but with different line endings
directly in %HOMEPATH%.

And, the data is within the user profile so that when accessed via
redirection or otherwise, the data is accessible on every machine the
user logs into.

Jeffrey Altman



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4529 bytes --]

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

On Nov 10, 2014, at 6:38 PM, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

> My personal preference would be for the Cygwin Home directory to be
> created under
> 
>  %HOMEPATH%\AppData\Roaming\Cygwin

That’s certainly the way you’re *supposed* to do it on Windows.

There’s some value in using %USERPROFILE% for this, however:

1. c:\Users\ShortName is directly analogous to /home/shortname on Linux or /Users/ShortName on OS X.

2. Recent versions of Windows have given up on the “My” prefix for the main directories within your user profile directory which happens to make them match the scheme used on Ubuntu, Fedora, OS X, etc.  Finger memory like “cd ~/Desktop” will serve you better if Cygwin doesn’t bury the user directory underneath AppData somewhere.

You can paper over #2 with symlinks, of course, as I already do while using the current c:\cygwin\home scheme.  It would just be nice to avoid the need to create those symlinks.  Symlinks don’t always behave exactly the same as real directories, for one thing.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 10 23:19, Warren Young wrote:
> On Nov 10, 2014, at 6:38 PM, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
> > My personal preference would be for the Cygwin Home directory to be
> > created under
> > 
> >  %HOMEPATH%\AppData\Roaming\Cygwin
> 
> That’s certainly the way you’re *supposed* to do it on Windows.
> 
> There’s some value in using %USERPROFILE% for this, however:
> 
> 1. c:\Users\ShortName is directly analogous to /home/shortname on
> Linux or /Users/ShortName on OS X.
> 
> 2. Recent versions of Windows have given up on the “My” prefix for the
> main directories within your user profile directory which happens to
> make them match the scheme used on Ubuntu, Fedora, OS X, etc.  Finger
> memory like “cd ~/Desktop” will serve you better if Cygwin doesn’t
> bury the user directory underneath AppData somewhere.
> 
> You can paper over #2 with symlinks, of course, as I already do while
> using the current c:\cygwin\home scheme.  It would just be nice to
> avoid the need to create those symlinks.  Symlinks don’t always behave
> exactly the same as real directories, for one thing.

Use mount points in /etc/fstab or /etc/fstab.d.  Mount points usually
behave like real directories.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 10 20:38, Jeffrey Altman wrote:
> On 11/10/2014 3:52 PM, Corinna Vinschen wrote:
> > Hi,
> > 
> > 
> > after a long discussion in RL today, I came to the conclusion that
> > there's a major problem in the current handling of the user's home
> > directory in AD environments in the new user account code when not using
> > /etc/passwd files.
> 
> 
> My personal preference would be for the Cygwin Home directory to be
> created under
> 
>   %HOMEPATH%\AppData\Roaming\Cygwin
> 
> That way the home directory is isolated from native windows applications
> that might use the same file names but with different line endings
> directly in %HOMEPATH%.
> 
> And, the data is within the user profile so that when accessed via
> redirection or otherwise, the data is accessible on every machine the
> user logs into.

I don't think that works as expected in all environments.

What you refer to above is not, in fact, %HOMEPATH%\AppData\Roaming\Cygwin,
but %USERPROFILE%\AppData\Roaming\Cygwin.

%USERPROFILE% and %HOMEPATH% are two different things, maintained
separately in AD.  The roaming user profile is often not the same
path as the homedir, it's just the lazy default.

The roaming user profile is loaded from the profile server every time
you log on to a machine.  If you have a big Cygwin home dir, you don't
want that to be part of your roaming profile and being loaded over the
net at login time.  

The homedir is typically on a fileserver which just gets connected to
your drive Z:.

Please keep in mind that I'm talking about the Cygwin home dir not as
a default value which can be overridden in /etc/passwd, but of a Cygwin
home dir as returned by Cygwin when fetching the passwd entry from AD,
and no passwd file exists.  This Cygwin home dir should be:

- Make some kind of sense when using a default value.

- Be configurable by the administrators if possible.

That's why I thought it a good idea to utilize unixHomeDirectory.
Default is /home/$USER,  The admins can set it to some other value
in POSIX notation.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Jeffrey Altman]

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

On 11/11/2014 4:59 AM, Corinna Vinschen wrote:
> Please keep in mind that I'm talking about the Cygwin home dir not as
> a default value which can be overridden in /etc/passwd, but of a Cygwin
> home dir as returned by Cygwin when fetching the passwd entry from AD,
> and no passwd file exists.  This Cygwin home dir should be:
> 
> - Make some kind of sense when using a default value.
> 
> - Be configurable by the administrators if possible.
> 
> That's why I thought it a good idea to utilize unixHomeDirectory.
> Default is /home/$USER,  The admins can set it to some other value
> in POSIX notation.

Using the unixHomeDirectory feels wrong to me because it doesn't provide
a context to indicate where the home directory is located. Its intended
purpose is to permit the specification of the home directory for UNIX
systems.  On a UNIX system it might be a local disk or /home might be on
one or more network file systems which might or might not be accessible
from a Windows system.   What would the behavior be if unixHomeDirectory was

  /afs/example.edu/users/j/e/jeff

and no AFS client was installed on the Windows system?

What would the behavior be if there was an AFS client installed on the
Windows system?   To access AFS from Windows would require UNC notation
not an absolute root.

Does a default location in the Windows profile make sense and permit
administrators to provide HKCU\SOFTWARE\Cygwin\ registry value to
indicate an alternative location?  Or perhaps a per-user environment
variable which would also be distributed via the user's registry hive.

Jeffrey Altman



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4529 bytes --]

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 11 08:51, Jeffrey Altman wrote:
> On 11/11/2014 4:59 AM, Corinna Vinschen wrote:
> > Please keep in mind that I'm talking about the Cygwin home dir not as
> > a default value which can be overridden in /etc/passwd, but of a Cygwin
> > home dir as returned by Cygwin when fetching the passwd entry from AD,
> > and no passwd file exists.  This Cygwin home dir should be:
> > 
> > - Make some kind of sense when using a default value.
> > 
> > - Be configurable by the administrators if possible.
> > 
> > That's why I thought it a good idea to utilize unixHomeDirectory.
> > Default is /home/$USER,  The admins can set it to some other value
> > in POSIX notation.
> 
> Using the unixHomeDirectory feels wrong to me because it doesn't provide
> a context to indicate where the home directory is located.

That's why I started this discussion in the first place.  "It seemed like
a good idea at the time", but not so anymore.

> Does a default location in the Windows profile make sense and permit
> administrators to provide HKCU\SOFTWARE\Cygwin\ registry value to
> indicate an alternative location?  Or perhaps a per-user environment
> variable which would also be distributed via the user's registry hive.

I'd prefer an admin-provided /etc/nsswitch.conf setting over registry
or environment... :}


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Yaakov Selkowitz]

On 2014-11-10 14:52, Corinna Vinschen wrote:
> When I implemented the new scheme I thought it a good idea to decouple
> the Cygwin home dir from the Windows home dir.  However, in the today's
> discussion the following two arguments came up:
>
> - If you're using the Windows home folder setting to maintain file
>    server based home directories, you typically want that these
>    directories are used for Cygwin stuff as well (central administration,
>    central backup).
>    Having to maintain the home directories twice, once in the
>    homeDirectory, once in the unixHomeDirectory entry is quite a hassle,
>    especially given that unixHomeDirectory does not support variable
>    substitution (e.g. "/home/%USERNAME%" won't work).
>
> - If you're already using AD as NIS server, unixHomeDirectory is already
>    used for UNIX machines.  Trying to align the unixHomeDirectory for
>    Cygwin to homeDirectory for all the rest of Windows will potentially
>    become impossible then.
>
> These arguments are quite serious and it questions the "good idea" part
> of this change a lot.
>
> What do you think?
>
> Shall the "db" entries utilize the Windows home folder if it exits(*)
> and drop using the unixHomeDirectory?  It seems inevitable...

If one uses the same program, one native Windows and one Cygwin, they 
would then potentially cause conflicting/incompatible config dot-files 
in the same directory (line endings, path conventions, etc.).


Yaakov


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

On Nov 10, 2014, at 9:26 PM, Yaakov Selkowitz <yselkowitz@cygwin.com> wrote:

> On 2014-11-10 14:52, Corinna Vinschen wrote:
>> 
>> Shall the "db" entries utilize the Windows home folder if it exits(*)
>> and drop using the unixHomeDirectory?  It seems inevitable...
> 
> If one uses the same program, one native Windows and one Cygwin, they would then potentially cause conflicting/incompatible config dot-files in the same directory (line endings, path conventions, etc.).

That’s only true if you make Cygwin $HOME == `cygpath -u %USERPROFILE%`.  If you put it somewhere under AppData/…/Cygwin, any non-Cygwin program that stomps on that directory isn’t following the platform rules.

Not that I think the risk of this is all that great.  I find that a lot of Windows software that comes from the Unix/Linux world already does something different with RC files and such.  Common schemes are:

1. Store files under AppData/…/AppName, where they won’t conflict with Cygwin $HOME == %USERPROFILE%

2. Name files and directories differently, often without leading dots, harkening back to the FAT naming limitations.  Leading underscores are a common alternative here.

Care to list some native Win32 ports that *do* put their user files in %USERPROFILE%, using the same naming scheme as on Linux/Unix except prefixed $HOME?
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Yaakov Selkowitz!

>> When I implemented the new scheme I thought it a good idea to decouple
>> the Cygwin home dir from the Windows home dir.  However, in the today's
>> discussion the following two arguments came up:
>>
>> - If you're using the Windows home folder setting to maintain file
>>    server based home directories, you typically want that these
>>    directories are used for Cygwin stuff as well (central administration,
>>    central backup).
>>    Having to maintain the home directories twice, once in the
>>    homeDirectory, once in the unixHomeDirectory entry is quite a hassle,
>>    especially given that unixHomeDirectory does not support variable
>>    substitution (e.g. "/home/%USERNAME%" won't work).
>>
>> - If you're already using AD as NIS server, unixHomeDirectory is already
>>    used for UNIX machines.  Trying to align the unixHomeDirectory for
>>    Cygwin to homeDirectory for all the rest of Windows will potentially
>>    become impossible then.
>>
>> These arguments are quite serious and it questions the "good idea" part
>> of this change a lot.
>>
>> What do you think?
>>
>> Shall the "db" entries utilize the Windows home folder if it exits(*)
>> and drop using the unixHomeDirectory?  It seems inevitable...

> If one uses the same program, one native Windows and one Cygwin, they 
> would then potentially cause conflicting/incompatible config dot-files 
> in the same directory (line endings, path conventions, etc.).

I would imagine using one or another. But not both. Native version of the same
program usually runs better, than the one running through compatibility layer.
Then again, many programs, that have native Windows version, use native
Windows conventions (I.e. put things in %AppData% rather than clogging
%USERPROFILE% with dot-dirs.)
Out of my list of programs, only GIMP and Dia would share the config dirs, if
I would try to set up Cygwin versions of either along with native one.
And all this worth nothing, because if someone's doing something like that,
they are either know what they are doing, and prepared for the possible
outcome, or deserve everything that could happen. IMO.
Not to mention, we're discussing default configuration here. You can alter it
easily to fit your needs, Cygwin gives you all that you need to achieve it.

In short, elusive benefits of having a separate cygwin-specific "clean" homes
versus confusing disjoint of multiple places to look for single user's files,
settings, and other stuff when it comes to backups and migrating profiles.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 11.11.2014, <09:28>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Marco Atzeri]

On 11/11/2014 7:40 AM, Andrey Repin wrote:
> Greetings, Yaakov Selkowitz!
>
>
> In short, elusive benefits of having a separate cygwin-specific "clean" homes
> versus confusing disjoint of multiple places to look for single user's files,
> settings, and other stuff when it comes to backups and migrating profiles.

This an extremely personal point of view.
For me, I strongly hate mixing my cygwin home with
standard windows one.
I prefer to have separate cygwin home also between 32 and 64 bit

> WBR,
> Andrey Repin

Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

On Nov 10, 2014, at 1:52 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

> Shall the "db" entries utilize the Windows home folder if it exits(*)
> and drop using the unixHomeDirectory?  It seems inevitable…

Use of AD implies some level of security consciousness.  The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator.

This answer I wrote on Stack Overflow is one way to solve the problem today:

    http://stackoverflow.com/questions/26666180/

It might not be a bad idea if Cygwin started doing this sort of thing by default in the future.  (Obviously for new installs only.)
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 10 23:09, Warren Young wrote:
> On Nov 10, 2014, at 1:52 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > Shall the "db" entries utilize the Windows home folder if it exits(*)
> > and drop using the unixHomeDirectory?  It seems inevitable…
> 
> Use of AD implies some level of security consciousness.  The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator.
> 
> This answer I wrote on Stack Overflow is one way to solve the problem today:
> 
>     http://stackoverflow.com/questions/26666180/
> 
> It might not be a bad idea if Cygwin started doing this sort of thing by default in the future.  (Obviously for new installs only.)

What I gather from the replies so far is this:

- Nobody really cares for unixHomeDirectory.

- Some want to use the Windows home folder.

- Some want Cygwin to utilize the HOMEPATH dir.

- Some want Cygwin to use always it's own /home and do everything else
  via symlinks or mount points.

The problem so far is that I'm not sure it's clear to everybody what
I mean.  I'm *not* talking about a default value which can easily be
overridden by tweaking /etc/passwd.  I'm talking about what the passwd
entry contains if there's no passwd file, and the admins want to keep
the administration strictly inside AD.  The passwd entry gets generated
from what AD provides.  And here we need a sensible default behaviour.

One possible, but not naturally useful default behaviour is what
the current code does:

1. Utilize the unixHomeDirectory AD attribute.
2. If unixHomeDirectory is empty, fall back to /home/$USER.

Another possible behaviour:

1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%).
2. If homeDirectory is empty, fall back to /home/$USER.

Another:

1. Always use /home/$USER and let the admins come up with a matching
   mount point scheme.

Another:

1. Add a setting to /etc/nsswitch.conf which allows to specify one of
  the above:

    home: [unix|win|home]...

   - "unix" means, set pw_dir to unixHomeDirectory
   - "win" means, set pw_dir to homeDirectory
   - "home" means, set pw_dir to /home/$USER
   - Multiple entries are possible.
   - Default in the absence of this setting is: always set pw_dir to
     /home/$USER.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> One possible, but not naturally useful default behaviour is what
> the current code does:
> 
> 1. Utilize the unixHomeDirectory AD attribute.
> 2. If unixHomeDirectory is empty, fall back to /home/$USER.
[...]

Default to /home/$USER unless a specific AD attribute is specified in some
configuration file (maybe nsswitch.conf, maybe something else) and that
attribute is non-empty.

> 1. Always use /home/$USER and let the admins come up with a matching
>    mount point scheme.

Would work for me, but then the configuration of those mount points would
need to be directable somehow.

> Another:
> 
> 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
>   the above:
> 
>     home: [unix|win|home]...
> 
>    - "unix" means, set pw_dir to unixHomeDirectory
>    - "win" means, set pw_dir to homeDirectory
>    - "home" means, set pw_dir to /home/$USER
>    - Multiple entries are possible.
>    - Default in the absence of this setting is: always set pw_dir to
>      /home/$USER.

Looks good, but maybe allow the AD attribute to be explicitly named (e.g.
cygwinHomeDirectory).  For local accounts maybe some environment variable or
registry key should be available as a configuration option.


Regards,
Achim.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 11 11:05, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > One possible, but not naturally useful default behaviour is what
> > the current code does:
> > 
> > 1. Utilize the unixHomeDirectory AD attribute.
> > 2. If unixHomeDirectory is empty, fall back to /home/$USER.
> [...]
> 
> Default to /home/$USER unless a specific AD attribute is specified in some
> configuration file (maybe nsswitch.conf, maybe something else) and that
> attribute is non-empty.
> 
> > 1. Always use /home/$USER and let the admins come up with a matching
> >    mount point scheme.
> 
> Would work for me, but then the configuration of those mount points would
> need to be directable somehow.
> 
> > Another:
> > 
> > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
> >   the above:
> > 
> >     home: [unix|win|home]...
> > 
> >    - "unix" means, set pw_dir to unixHomeDirectory
> >    - "win" means, set pw_dir to homeDirectory
> >    - "home" means, set pw_dir to /home/$USER
> >    - Multiple entries are possible.
> >    - Default in the absence of this setting is: always set pw_dir to
> >      /home/$USER.
> 
> Looks good, but maybe allow the AD attribute to be explicitly named (e.g.
> cygwinHomeDirectory).

Cygwin schema extension? :)

> For local accounts maybe some environment variable or
> registry key should be available as a configuration option.

I'm not that concerned about SAM accounts.  Typically they have no
problem with /home/$USER anyway, and they have the SAM description field
to add cygwin-specific data.


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 --]

RE: RFC: 1.7.33 problem with user's home directory

[Habermann, David (D)]

>>> Another:
>>> 
>>> 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
>>>   the above:
>>> 
>>>     home: [unix|win|home]...
>>> 
>>>    - "unix" means, set pw_dir to unixHomeDirectory
>>>    - "win" means, set pw_dir to homeDirectory
>>>    - "home" means, set pw_dir to /home/$USER
>>>    - Multiple entries are possible.
>>>    - Default in the absence of this setting is: always set pw_dir to
>>>      /home/$USER.
> 
>> Looks good, but maybe allow the AD attribute to be explicitly named (e.g.
>> cygwinHomeDirectory).
>
>Cygwin schema extension? :)

Sorry to join in the fun here so late, but I like the current behavior and really don't see any reason (given my usage) why I'd want to mix my cygwin and windows files together in the same directory.  Additionally, I don't have the ability to change the unixHomeDirectory field in our AD.  I also like having everything stored under one main directory (c:\cygwin) for ease of backup and ease of identification of all cygwin-involved files for our virus and our application whitelisting systems.

As I result, if folks feel that something must be done, I like the plan above.  I don't really care what the default behavior is, so long as the "home: home" option is available.

Dave

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

On Nov 11, 2014, at 5:47 AM, Habermann, David (D) <DAHabermann@dow.com> wrote:

> I also like having everything stored under one main directory (c:\cygwin) for ease of backup

Why would you back up all of c:\cygwin?  Most of it is downloaded from the Internet, and this is easily reinstalled from your cached download.  (I’m assuming you keep setup.exe and its download tree on a network drive somewhere.)

My starting point for backup on Unix boxes is to exclude everything except /etc, /home and /usr/local.  Then maybe add a few choice things under /var.  Everything else can be reinstalled.

Since I’m already cherry-picking what to back up, it doesn’t matter to me that /home might be somewhere physically different than /usr.

c:\Users should be part of your backups anyway.

> and ease of identification of all cygwin-involved files for our virus and our application whitelisting systems.

Do you really have executables in $HOME/bin that won’t run unless whitelisted?  Does your security software actually ban programs in %HOMEPATH%?

I can see the need to smack the AV with a clue-bat occasionally for some things under /usr, if only to address false positives.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

On Nov 11, 2014, at 5:47 AM, Habermann, David (D) <DAHabermann@dow.com> wrote:

> I also like having everything stored under one main directory (c:\cygwin) for ease of backup

Why would you back up all of c:\cygwin?  Most of it is downloaded from the Internet, and this is easily reinstalled from your cached download.  (I’m assuming you keep setup.exe and its download tree on a network drive somewhere.)

My starting point for backup on Unix boxes is to exclude everything except /etc, /home and /usr/local.  Then maybe add a few choice things under /var.  Everything else can be reinstalled.

Since I’m already cherry-picking what to back up, it doesn’t matter to me that /home might be somewhere physically different than /usr.

c:\Users should be part of your backups anyway.

> and ease of identification of all cygwin-involved files for our virus and our application whitelisting systems.

Do you really have executables in $HOME/bin that won’t run unless whitelisted?  Does your security software actually ban programs in %HOMEPATH%?

I can see the need to smack the AV with a clue-bat occasionally for some things under /usr, if only to address false positives.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: RFC: 1.7.33 problem with user's home directory

[Habermann, David (D)]

>> I also like having everything stored under one main directory (c:\cygwin) for ease of backup

> Why would you back up all of c:\cygwin?  Most of it is downloaded from the Internet, and this is easily
> reinstalled from your cached download.  (I'm assuming you keep setup.exe and its download tree on a 
> network drive somewhere.)

I do something similar to you, and the backup isn't the big issue (although I do have MANY locally compiled programs here).  C:\Users is backed up by the corporation, so I either have to duplicate the backup or do multiple recoveries from different backup systems to get it all back...that is why I prefer c:\cygwin\home

My starting point for backup on Unix boxes is to exclude everything except /etc, /home and /usr/local.  Then maybe add a few choice things under /var.  Everything else can be reinstalled.

>> and ease of identification of all cygwin-involved files for our virus and our application 
>> whitelisting systems.

> Do you really have executables in $HOME/bin that won't run unless whitelisted?  Does your security 
> software actually ban programs in %HOMEPATH%?

In our corporate environment, ALL programs (exe, dll, bat, shells and numerous others) on ALL PATHS must be on a corporate-enforced whitelist before they will run at all.  Typically even new versions must be whitelisted, although I've been able to negotiate a folder-and-workstation-specific blanket approval.  I'd like to suggest that we be sensitive to application whitelisting systems, as many corporations are moving in that direction (as it nearly eliminates virus problems altogether)....and yes, working in such an environment is a true PITA.

Also, in general I simply don't like mixing my corporate files (Office software, etc.) with my cygwin files.  They are unrelated and so I like to keep them separate.  Perhaps it is a personal preference, but it is an option I wouldn't want to lose....it would probably force me back to using the passwd file instead of the db.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[cyg Simple]

On Wed, Nov 12, 2014 at 12:55 PM, Habermann, David (D) wrote:
>>> I also like having everything stored under one main directory (c:\cygwin) for ease of backup
>
>> Why would you back up all of c:\cygwin?  Most of it is downloaded from the Internet, and this is easily
>> reinstalled from your cached download.  (I'm assuming you keep setup.exe and its download tree on a
>> network drive somewhere.)
>
> I do something similar to you, and the backup isn't the big issue (although I do have MANY locally compiled programs here).  C:\Users is backed up by the corporation, so I either have to duplicate the backup or do multiple recoveries from different backup systems to get it all back...that is why I prefer c:\cygwin\home
>

I would have to stop using Cygwin if what is being proposed is put
into action unless I can thwart it by specifying that it uses the
current scenario.  Besides, it is nice to have the Cygwin HOME
directory isolated to the Cygwin installation for a portable install
that can be used on a USB thumb drive.

Thumb drive use requires mkpasswd/mkgroup -c >> /etc/passwd/group with
careful security management but it can be done!

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: RFC: 1.7.33 problem with user's home directory

[Habermann, David (D)]

> current scenario.  Besides, it is nice to have the Cygwin HOME
> directory isolated to the Cygwin installation for a portable install
> that can be used on a USB thumb drive.

I hadn't even thought about thumb drive/portable use since I hadn't used mine for a while.  I, too, will have to work around any change to the current home directory location in order to continue use.  For the moment at least we can always fall back onto specifying these things in the passwd file, although I already like the new AD system and hope I don't have to abandon it.

Dave

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 12 21:51, Habermann, David (D) wrote:
> > current scenario.  Besides, it is nice to have the Cygwin HOME
> > directory isolated to the Cygwin installation for a portable install
> > that can be used on a USB thumb drive.
> 
> I hadn't even thought about thumb drive/portable use since I hadn't
> used mine for a while.  I, too, will have to work around any change to
> the current home directory location in order to continue use.  For the
> moment at least we can always fall back onto specifying these things
> in the passwd file, although I already like the new AD system and hope
> I don't have to abandon it.

The idea of this discussion is to find a solution which works for
everybody.  In theory, the default should work for all or at least most
home users.  For AD environments I expect that admins already know that
a bit of tweaking is required, here I'm looking for something which
doesn't make the job too hard.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, cyg Simple!

> On Wed, Nov 12, 2014 at 12:55 PM, Habermann, David (D) wrote:
>>>> I also like having everything stored under one main directory (c:\cygwin) for ease of backup
>>
>>> Why would you back up all of c:\cygwin?  Most of it is downloaded from the
>>> Internet, and this is easily reinstalled from your cached download.  (I'm
>>> assuming you keep setup.exe and its download tree on a
>>> network drive somewhere.)
>>
>> I do something similar to you, and the backup isn't the big issue (although
>> I do have MANY locally compiled programs here).  C:\Users is backed up by
>> the corporation, so I either have to duplicate the backup or do multiple
>> recoveries from different backup systems to get it all back...that is why I
>> prefer c:\cygwin\home

> I would have to stop using Cygwin if what is being proposed is put
> into action unless I can thwart it by specifying that it uses the
> current scenario.  Besides, it is nice to have the Cygwin HOME
> directory isolated to the Cygwin installation for a portable install
> that can be used on a USB thumb drive.

> Thumb drive use requires mkpasswd/mkgroup -c >> /etc/passwd/group with
> careful security management but it can be done!

Can you, perhaps, stop exalting and start reading? Noone said you won't be
able to use current scheme, one way or another.
Read Corinna's question and understand it, before replying.
We need to decide on a sensible DEFAULT behavior, AND a set of ALTERNATIVES,
because, obviously, default setting will never suit every use case.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 13.11.2014, <01:29>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Achim Gratz]

Corinna Vinschen writes:
>> Looks good, but maybe allow the AD attribute to be explicitly named (e.g.
>> cygwinHomeDirectory).
>
> Cygwin schema extension? :)

I don't see why not, given that there's the possibility of having
different information for Windows, Cygwin and UNIX in the same AD.  But
more realistically, one of the extensionAttributes that Exchange plugs
in anyway could keep that information.

>> For local accounts maybe some environment variable or
>> registry key should be available as a configuration option.
>
> I'm not that concerned about SAM accounts.  Typically they have no
> problem with /home/$USER anyway, and they have the SAM description field
> to add cygwin-specific data.

OK.  We'll find out soon enough how to set up a local sshd account
anyway.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 11 17:44, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> Looks good, but maybe allow the AD attribute to be explicitly named (e.g.
> >> cygwinHomeDirectory).
> >
> > Cygwin schema extension? :)
> 
> I don't see why not, given that there's the possibility of having
> different information for Windows, Cygwin and UNIX in the same AD.

It's a bit complicated.  You need a way to distinguish the name of an
attribute from simple values like "home", or "cygwin" as Andrey
proposes.  My simply Cygwin-internal LDAP interface has no way of
providing arbitrary attribute strings either, so that needs to be
extended first.

Microsoft themselves use XML strings in some attribute blobs for
TS settings and stuff, so maybe the description field should be
sufficient.  I'm wondering if we really need other attributes then.

> But
> more realistically, one of the extensionAttributes that Exchange plugs
> in anyway could keep that information.

I have no experience with Exchange, so I can't tell.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 11 12:14, Corinna Vinschen wrote:
> On Nov 11 11:05, Achim Gratz wrote:
> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
> > >   the above:
> > > 
> > >     home: [unix|win|home]...
> > > 
> > >    - "unix" means, set pw_dir to unixHomeDirectory
> > >    - "win" means, set pw_dir to homeDirectory
> > >    - "home" means, set pw_dir to /home/$USER
> > >    - Multiple entries are possible.
> > >    - Default in the absence of this setting is: always set pw_dir to
> > >      /home/$USER.
> > 
> > Looks good, but maybe allow the AD attribute to be explicitly named (e.g.
> > cygwinHomeDirectory).
> 
> Cygwin schema extension? :)

I just created a patch and a matching snapshot on
https://cygwin.com/snapshots/

The new stuff is still missing documentation, so I'm explaining it here
for now.

For the attentive, there are two questions in the text...

Here's what you get:

/etc/nsswitch.conf now supports specifying three new settings which
allow to configure the pw_dir, pw_shell, and pw_gecos content:

  db_home: schema...
  db_shell: schema...
  db_gecos: schema...

"schema..." is a list of up to four space-separated schemata:

  db_home: schema1 schema2 ...

If the first schema returns an empty string, skip to the second, and
so on.  Schemata only supported on AD are silently skipped for SAM
accounts and on non-AD machines.

The default for all three settings is:

  db_foo:  cygwin desc

Four predefined schemata are supported:

  windows           Utilizes typical Windows settings.  Supported for
		    AD and SAM accounts.

  cygwin            Utilizes predefined cygwinUser/cygwinGroup AD schema
                    extensions.  These are available via a schema extension
		    file /usr/share/cygwin/cygwin.ldif.

  unix              Utilizes the RFC2307 posixAccount/posixGroup schema
		    extensions.  These are available when installing the
		    Server for NIS AD feature.

  desc              Utilizes XML-style attributes in the description
                    attribute.  Supported for AD and SAM accounts.  This
		    way to fetch extended user and group info from the
		    description field is already documented (albeit only
		    for SAM accounts) in
		    https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo:

Two variable schemata are supported:

  @ad_attribute     ad_attribute is any arbitrary AD attribute name which
		    should be available in the User class or in any attached
		    auxiliary class.

  /path             An arbitrary string, typically a path.  The leading slash
		    is required.  The /path schema supports a few wildcards:

		      %u   Cygwin username
		      %U   Windows username
		      %D   Windows domain in NetBIOS style
		      %_   A space
		      %%   A percent sign.

The meaning of the schemata depend on the setting:

  db_home:

    windows         AD and SAM: Utilizes the setting of the homeDrive or
		    homeDirectory attributes, or their SAM "Home folder"
		    counterparts.  The Windows path is converted to a
		    POSIX path.

    cygwin          AD only: Shortcut for the cygwinHome attribute from
                    the predefined cygwinUser auxiliary class.  POSIX path
		    expected.

    unix            AD only: Shortcut for the unixHomeDirectory attribute
		    from the posixAccount auxiliary class.  POSIX path
		    expected.

    desc            AD and SAM: Fetch the home="..."
                    setting from the user's description attribute.
		    POSIX path expected.

    @ad_attribute   AD-only: Read AD attribute "ad_attribute" as POSIX
		    path.
		    
		    However, I'm contemplating to allow a Windows path
		    here, too.  Does this make sense to you?

    /path	    POSIX path.  Remember the wildcards.

    fallback        If nothing works, the fallback is /home/$USERNAME
                    (Windows username).


  db_shell:

    windows         Ignored.  Do you want CMD instead?

    cygwin          AD-only: Shortcut for the cygwinShell attribute
		    from the cygwinUser class.  POSIX path.

    unix            AD-only: Shortcut for the loginShell attribute
		    from the posixAccount class.  POSIX path.

    desc            AD and SAM: Fetch the shell="" setting from the
		    user's description attribute.  POSIX path.

    @ad_attribute   See above.

    /path	    See above.

    fallback        If nothing works, the fallback is /bin/bash.


  db_gecos:

    windows         AD and SAM: displayName attribute, or "Full Name"
		    setting in SAM. 

    cygwin          AD-only: cygwinGecos attribute from cygwinUser class.

    unix            AD-only: gecos attribute from posixAccount class.

    @ad_attribute   Read AD attribute "ad_attribute" and prepend
                    to pw_gecos.

    /path	    Skip the slash, prepend the reminder of the string
                    to pw_gecos.  Note that the wildcards are still
		    evaluated.

    fallback        If nothing works, the fallback is no fallback.


Examples:

  db_home: cygwin desc

    The default.  Try the cygwinHome attribute first. If it's empty,
    evalaute the description field and see if the home dir is set via
    the cygwin XML-style text.  If that fails, fallback is /home/$USERNAME
    (Windows username).

  db_home: unix @msTSHomeDirectory /home/%u

    Try the unixHomeDirectory attribute first.  Empty?  Try the
    (otherwise unused) msTSHomeDirectory attribute.  Empty?  Fall back
    to /home/$USER (Cygwin username).

  db_gecos: @comment /Hallo%_%U

    Try the comment attribute.  Empty?  Fall back to the string
    "Hallo <Windows username>".  Example passwd entry:

      corinna:*:1049577:1049701:Hallo corinna,U-MY_DOM\corinna,S-1-5-21-yada-yada:/home/corinna:/bin/bash

Is this new stuff basically clear?  Questions?

Please give it a try.


Thanks,
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 --]

Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Corinna Vinschen]

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

On Nov 26 21:56, Corinna Vinschen wrote:
> > Cygwin schema extension? :)
> 
> I just created a patch and a matching snapshot on
> https://cygwin.com/snapshots/

Ok, so we have a cygwin schema extension now.  The file is called
cygwin.ldif and is in the Cygwin CVS repo.  It gets installed to
/usr/share/cygwin.  The schema extension consists of two auxiliary
classes:

  CN=cygwinUser, gets attached to CN=User and adds the attributes:

    cygwinHome
    cygwinShell
    cygwinGecos

  as well as the as of yet unused

    cygwinUnixUid
    cywinFstab

  CN=cygwinGroup, gets attached to CN=Group and adds the attribute:

    cygwinUinxGid

The cygwinHome, cygwinShell and cygwinGecos attributes are described
in my previous mail.

cygwinUnixUid and cygwinUinxGid are supposed to be used for NFS and
Samba uid/gid account mapping, same as the posixAccount:uidNumber,
and posixGroup:gidNumber fields.  See
https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-nfs
https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-samba

cygwinFstab, a multi-string attribute, is supposed to be used as
user fstab, along the lines, but replacing the /etc/fstab.d/$USER
file.  This way an administrator can predefine per-user mount points.

In the long run I'm also planning to allow replacing /etc/fstab and
/etc/nsswitch.conf with a Cygwin-specific AD configuration extension.

The idea of this, including the cygwinFstab attribute, is to allow
admins to get rid of any local system setting, to control the Cygwin
system settings entirely from AD, and to drop the requirement for
/etc being always alongside of Cygwin's /bin dir.

Do you think this makes sense?  Would you actually use these AD
extensions, or do you see your admins using them if available?


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 --]

Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Achim Gratz]

Corinna Vinschen writes:
> Ok, so we have a cygwin schema extension now.  The file is called
> cygwin.ldif and is in the Cygwin CVS repo.  It gets installed to
> /usr/share/cygwin.  The schema extension consists of two auxiliary
> classes:
[…]
> Do you think this makes sense?  Would you actually use these AD
> extensions, or do you see your admins using them if available?

This is _very_ interesting and I hope to have some discussion with our
AD admins about this.  It will be some time though, there is just too
many other things going on right now.  But if they allow this to be
used, I think it would indeed be possible to get rid of all local
configuration for a new install on a client machine.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Corinna Vinschen]

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

On Nov 26 22:28, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Ok, so we have a cygwin schema extension now.  The file is called
> > cygwin.ldif and is in the Cygwin CVS repo.  It gets installed to
> > /usr/share/cygwin.  The schema extension consists of two auxiliary
> > classes:
> […]
> > Do you think this makes sense?  Would you actually use these AD
> > extensions, or do you see your admins using them if available?
> 
> This is _very_ interesting and I hope to have some discussion with our
> AD admins about this.  It will be some time though, there is just too
> many other things going on right now.  But if they allow this to be
> used, I think it would indeed be possible to get rid of all local
> configuration for a new install on a client machine.

It would be possible for sure.  The question is, would it be actually
used?  In some environments, schema and configuration extensions are
avoided like the plague.


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 --]

Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Corinna Vinschen]

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

On Nov 26 22:58, Corinna Vinschen wrote:
> On Nov 26 22:28, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > Ok, so we have a cygwin schema extension now.  The file is called
> > > cygwin.ldif and is in the Cygwin CVS repo.  It gets installed to
> > > /usr/share/cygwin.  The schema extension consists of two auxiliary
> > > classes:
> > […]
> > > Do you think this makes sense?  Would you actually use these AD
> > > extensions, or do you see your admins using them if available?
> > 
> > This is _very_ interesting and I hope to have some discussion with our
> > AD admins about this.  It will be some time though, there is just too
> > many other things going on right now.  But if they allow this to be
> > used, I think it would indeed be possible to get rid of all local
> > configuration for a new install on a client machine.
> 
> It would be possible for sure.  The question is, would it be actually
> used?  In some environments, schema and configuration extensions are
> avoided like the plague.

Oh, btw. since you're mentioning this will take time... it will take
time from my side as well.  I'm not planning to implement reading fstab
and nsswitch contents from AD in 2014.

That's something for 2015, and it depends on you guys, either in helping
defining the layout of the AD configuration, or even helping coding:

Ideally, such a configuration extension requires a new tool for Admins.
It's not exactly feasible for an Admin to install and maintain the
configuration extension in ADSI Edit.

At least a CLI tool to install and maintain the settings would be
needed.  A GUI tool would be the hit.


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 --]

Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Achim Gratz]

Corinna Vinschen writes:
> Ideally, such a configuration extension requires a new tool for Admins.
> It's not exactly feasible for an Admin to install and maintain the
> configuration extension in ADSI Edit.

In practise IT would do these edits via a dedicated web interface that
takes most of its data from the install order form.  As long as they
don't have to install any extra interface libraries or server components
they likely don't have a problem once they know the names and layout.

> At least a CLI tool to install and maintain the settings would be
> needed.  A GUI tool would be the hit.

I'm not sure how large the user base of this might be.  Around here even
the AD administrators are pretty much restricted from using any edit
functionality such tools might provide since all changes must have a
documentation trail.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Corinna Vinschen]

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

On Nov 27 18:47, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Ideally, such a configuration extension requires a new tool for Admins.
> > It's not exactly feasible for an Admin to install and maintain the
> > configuration extension in ADSI Edit.
> 
> In practise IT would do these edits via a dedicated web interface that
> takes most of its data from the install order form.

-v please?  Is there something available out of the box?  Please keep in
mind that I'm not an admin.  ADSI Edit is perfectly fine for my limited
usage of AD.

> As long as they
> don't have to install any extra interface libraries or server components
> they likely don't have a problem once they know the names and layout.
> 
> > At least a CLI tool to install and maintain the settings would be
> > needed.  A GUI tool would be the hit.
> 
> I'm not sure how large the user base of this might be.  Around here even
> the AD administrators are pretty much restricted from using any edit
> functionality such tools might provide since all changes must have a
> documentation trail.

Maybe I'm too far off, but to me documentation requirements don't
exclude the use of certain tools...


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 --]

Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Achim Gratz]

Corinna Vinschen writes:
>> In practise IT would do these edits via a dedicated web interface that
>> takes most of its data from the install order form.
>
> -v please?  Is there something available out of the box?  Please keep in
> mind that I'm not an admin.  ADSI Edit is perfectly fine for my limited
> usage of AD.

I don't really know, but that's how they (have to) do all the other
stuff, see below.

> Maybe I'm too far off, but to me documentation requirements don't
> exclude the use of certain tools...

Technically not, but the associated compliance regulations and policies
do.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Habermann, David (D)]

> In the long run I'm also planning to allow replacing /etc/fstab and
> /etc/nsswitch.conf with a Cygwin-specific AD configuration extension.

While I can see how this might be attractive for some, I see it as something that must be an optional replacement of the /etc/fstab and /etc/nsswitch.conf files, as in my case the AD is totally outside of my control and these additions will never be implemented.

Dave

Re: Cygwin AD schema and configuration extensions (was Re: RFC: 1.7.33 problem with user's home directory)

[Corinna Vinschen]

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

On Nov 26 21:44, Habermann, David (D) wrote:
> > In the long run I'm also planning to allow replacing /etc/fstab and
> > /etc/nsswitch.conf with a Cygwin-specific AD configuration extension.
> 
> While I can see how this might be attractive for some, I see it as
> something that must be an optional replacement of the /etc/fstab and
> /etc/nsswitch.conf files, as in my case the AD is totally outside of
> my control and these additions will never be implemented.

Sure, no worries.  I wasn't talking about removing support for the
/etc/fstab and /etc/nsswitch.conf files, but to add another technique
for admins.  The files are absolutely required for non-AD machines
anyway.  The idea was going along these lines.  At Cygwin startup:

- On a domain machine, request the configuration extension for
  nsswitch.conf from AD.  If it exists use it.
- If it doesn't exist, or if the machine is a non-AD machine, check the
  file.

Same for /etc/fstab.

After creating the passwd entry for the current user, check for
the user's cygwinFstab attribute.  If it's not empty, use it,
otherwise, or on a non-AD machine, use the /etc/fstab.d/$USER file.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 26 21:56, Corinna Vinschen wrote:
>   db_gecos:
> 
>     windows         AD and SAM: displayName attribute, or "Full Name"
> 		    setting in SAM. 
> 
>     cygwin          AD-only: cygwinGecos attribute from cygwinUser class.
> 
>     unix            AD-only: gecos attribute from posixAccount class.
> 

I forgot "desc' here:

      desc            AD and SAM: Fetch the gecos="" setting from the
  		    user's description attribute.  POSIX path.

>     @ad_attribute   Read AD attribute "ad_attribute" and prepend
>                     to pw_gecos.
> 
>     /path	    Skip the slash, prepend the reminder of the string
>                     to pw_gecos.  Note that the wildcards are still
> 		    evaluated.
> 
>     fallback        If nothing works, the fallback is no fallback.


Sorry,
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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 26 21:56, Corinna Vinschen wrote:
> The meaning of the schemata depend on the setting:
> 
>   db_home:
> 
>     windows         AD and SAM: Utilizes the setting of the homeDrive or
> 		    homeDirectory attributes, or their SAM "Home folder"
> 		    counterparts.  The Windows path is converted to a
> 		    POSIX path.

I'm not really happy with this.  It requires to write some value to the
homeDrive/homeDirectory attributes, because it doesn't fall back to the
Windows default values.

So, another question is this:  Shall "db_home: windows" fall back
to the default Windows home dir if homeDrive/homeDirectory are empty?

>     cygwin          AD only: Shortcut for the cygwinHome attribute from
>                     the predefined cygwinUser auxiliary class.  POSIX path
> 		    expected.
> 
>     unix            AD only: Shortcut for the unixHomeDirectory attribute
> 		    from the posixAccount auxiliary class.  POSIX path
> 		    expected.
> 
>     desc            AD and SAM: Fetch the home="..."
>                     setting from the user's description attribute.
> 		    POSIX path expected.
> 
>     @ad_attribute   AD-only: Read AD attribute "ad_attribute" as POSIX
> 		    path.
> 		    
> 		    However, I'm contemplating to allow a Windows path
> 		    here, too.  Does this make sense to you?

I implemented this now.  It doesn't hurt.

>     /path	    POSIX path.  Remember the wildcards.
> 
>     fallback        If nothing works, the fallback is /home/$USERNAME
>                     (Windows username).
> 
> 
>   db_shell:
> 
>     windows         Ignored.  Do you want CMD instead?

Would be interesting for symmetry only, I guess...


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> The meaning of the schemata depend on the setting:
>> 
>>   db_home:
>> 
>>     windows         AD and SAM: Utilizes the setting of the homeDrive or
>>                   homeDirectory attributes, or their SAM "Home folder"
>>                   counterparts.  The Windows path is converted to a
>>                   POSIX path.

> I'm not really happy with this.  It requires to write some value to the
> homeDrive/homeDirectory attributes, because it doesn't fall back to the
> Windows default values.

> So, another question is this:  Shall "db_home: windows" fall back
> to the default Windows home dir if homeDrive/homeDirectory are empty?

Yes, if you mean it.
I mean, if you intend to use the same directory OS using for user's home
directory, you gotta use something that resembles the OS behavior.

>>     @ad_attribute   AD-only: Read AD attribute "ad_attribute" as POSIX
>>                   path.
>>                   
>>                   However, I'm contemplating to allow a Windows path
>>                   here, too.  Does this make sense to you?

> I implemented this now.  It doesn't hurt.

Windows path here makes more sense. The translation to POSIX path depends
on the fstab settings, and may vary across different systems, and even
different users, given your aim to make fstab configurable per-user. (Am I
reading it right?)

>>     /path         POSIX path.  Remember the wildcards.
>> 
>>     fallback        If nothing works, the fallback is /home/$USERNAME
>>                     (Windows username).
>> 
>> 
>>   db_shell:
>> 
>>     windows         Ignored.  Do you want CMD instead?

> Would be interesting for symmetry only, I guess...

With bogus quoting rules of CMD? It would just not work straight, I'm
afraid. May be better with PS, but I'm not familiar with it, and I don't know
anyone, who's familiar or even considering it's use as a shell interpreter.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 28.11.2014, <14:52>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 28 15:08, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> The meaning of the schemata depend on the setting:
> >> 
> >>   db_home:
> >> 
> >>     windows         AD and SAM: Utilizes the setting of the homeDrive or
> >>                   homeDirectory attributes, or their SAM "Home folder"
> >>                   counterparts.  The Windows path is converted to a
> >>                   POSIX path.
> 
> > I'm not really happy with this.  It requires to write some value to the
> > homeDrive/homeDirectory attributes, because it doesn't fall back to the
> > Windows default values.
> 
> > So, another question is this:  Shall "db_home: windows" fall back
> > to the default Windows home dir if homeDrive/homeDirectory are empty?
> 
> Yes, if you mean it.
> I mean, if you intend to use the same directory OS using for user's home
> directory, you gotta use something that resembles the OS behavior.

Good point.  It's just a bit lengthy to implement.

> >>     @ad_attribute   AD-only: Read AD attribute "ad_attribute" as POSIX
> >>                   path.
> >>                   
> >>                   However, I'm contemplating to allow a Windows path
> >>                   here, too.  Does this make sense to you?
> 
> > I implemented this now.  It doesn't hurt.
> 
> Windows path here makes more sense. The translation to POSIX path depends
> on the fstab settings, and may vary across different systems, and even
> different users, given your aim to make fstab configurable per-user. (Am I
> reading it right?)

We already have user mount points in /etc/fstab.d.  Reading them from AD
only changes the point of administration.  In many organizations the
client machines use a standarized layout anyway.  Allowing a DOS path
here just adds convenience for admins feeling uncomfortable with POSIX
paths.

> >>   db_shell:
> >> 
> >>     windows         Ignored.  Do you want CMD instead?
> 
> > Would be interesting for symmetry only, I guess...
> 
> With bogus quoting rules of CMD? It would just not work straight, I'm
> afraid. May be better with PS, but I'm not familiar with it, and I don't know
> anyone, who's familiar or even considering it's use as a shell interpreter.

Lots of people do.  You won't believe in how many scenarios the
users use Cygwin tools from CMD.  If we implement the above, we
would just have to add a cmd wrapper script in /bin to make sure
$PATH is set correctly and to make sure CMD starts up in $HOME,
something along the lines of:

  $ cat /bin/cmd
  #!/bin/dash
  PATH=/bin:$PATH
  cd $HOME
  # Don't rely on COMSPEC!
  cmd=$(cygpath -ua "${SYSTEMROOT}\\System32\\CMD.EXE")
  exec "${cmd}"

  
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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> The meaning of the schemata depend on the setting:
>> >> 
>> >>   db_home:
>> >> 
>> >>     windows         AD and SAM: Utilizes the setting of the homeDrive or
>> >>                   homeDirectory attributes, or their SAM "Home folder"
>> >>                   counterparts.  The Windows path is converted to a
>> >>                   POSIX path.
>> 
>> > I'm not really happy with this.  It requires to write some value to the
>> > homeDrive/homeDirectory attributes, because it doesn't fall back to the
>> > Windows default values.
>> 
>> > So, another question is this:  Shall "db_home: windows" fall back
>> > to the default Windows home dir if homeDrive/homeDirectory are empty?
>> 
>> Yes, if you mean it.
>> I mean, if you intend to use the same directory OS using for user's home
>> directory, you gotta use something that resembles the OS behavior.

> Good point.  It's just a bit lengthy to implement.

I can imagine.

>> >>   db_shell:
>> >> 
>> >>     windows         Ignored.  Do you want CMD instead?
>> 
>> > Would be interesting for symmetry only, I guess...
>> 
>> With bogus quoting rules of CMD? It would just not work straight, I'm
>> afraid. May be better with PS, but I'm not familiar with it, and I don't know
>> anyone, who's familiar or even considering it's use as a shell interpreter.

> Lots of people do.  You won't believe in how many scenarios the
> users use Cygwin tools from CMD.

I trust you. For I'm one of those people, is not for any other reason.
However, I know exactly what I'm doing, and what to expect from it all.

> If we implement the above, we
> would just have to add a cmd wrapper script in /bin to make sure
> $PATH is set correctly and to make sure CMD starts up in $HOME,
> something along the lines of:

>   $ cat /bin/cmd
>   #!/bin/dash
>   PATH=/bin:$PATH
>   cd $HOME
>   # Don't rely on COMSPEC!
>   cmd=$(cygpath -ua "${SYSTEMROOT}\\System32\\CMD.EXE")
>   exec "${cmd}"

I hope you don't expect it to work inside mintty. Cygwin tools may function
properly in this case, but the shell itself - I have my doubts. And other
native tools would certainly have issues with encoding, if not with any output
at all.
Said that, it would need to be a simple .cmd file, so that it'd run in native
console.
Something like

@ECHO OFF
PATH=%~dp0;%PATH%
START "" /B "%SystemRoot%\System32\cmd.exe" /K
EXIT


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 28.11.2014, <18:17>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 28 19:08, Andrey Repin wrote:
> > If we implement the above, we
> > would just have to add a cmd wrapper script in /bin to make sure
> > $PATH is set correctly and to make sure CMD starts up in $HOME,
> > something along the lines of:
> 
> >   $ cat /bin/cmd
> >   #!/bin/dash
> >   PATH=/bin:$PATH
> >   cd $HOME
> >   # Don't rely on COMSPEC!
> >   cmd=$(cygpath -ua "${SYSTEMROOT}\\System32\\CMD.EXE")
> >   exec "${cmd}"
> 
> I hope you don't expect it to work inside mintty.

Oh, it does.  CMD itself isn't the biggest problem, many other native
tools are.

> Cygwin tools may function
> properly in this case, but the shell itself - I have my doubts. And other
> native tools would certainly have issues with encoding, if not with any output
> at all.
> Said that, it would need to be a simple .cmd file, so that it'd run in native
> console.
> Something like
> 
> @ECHO OFF
> PATH=%~dp0;%PATH%
> START "" /B "%SystemRoot%\System32\cmd.exe" /K
> EXIT

Fine with me, but it also has to cd to %HOME%, which is given in
POSIX syntax...


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

> On Nov 28 19:08, Andrey Repin wrote:
>> > If we implement the above, we
>> > would just have to add a cmd wrapper script in /bin to make sure
>> > $PATH is set correctly and to make sure CMD starts up in $HOME,
>> > something along the lines of:
>> 
>> >   $ cat /bin/cmd
>> >   #!/bin/dash
>> >   PATH=/bin:$PATH
>> >   cd $HOME
>> >   # Don't rely on COMSPEC!
>> >   cmd=$(cygpath -ua "${SYSTEMROOT}\\System32\\CMD.EXE")
>> >   exec "${cmd}"
>> 
>> I hope you don't expect it to work inside mintty.

> Oh, it does.  CMD itself isn't the biggest problem, many other native
> tools are.

Yes, CMD itself do output... something. As long as encoding isn't an issue.
But I have PROMPT=%USERNAME%%COMPUTERNAME%. Imagine if one of them turned out
to contain non-ASCII characters.

>> Cygwin tools may function
>> properly in this case, but the shell itself - I have my doubts. And other
>> native tools would certainly have issues with encoding, if not with any output
>> at all.
>> Said that, it would need to be a simple .cmd file, so that it'd run in native
>> console.
>> Something like
>> 
>> @ECHO OFF
>> PATH=%~dp0;%PATH%
>> START "" /B "%SystemRoot%\System32\cmd.exe" /K
>> EXIT

> Fine with me, but it also has to cd to %HOME%, which is given in
> POSIX syntax...

That may be an issue, unless %HOME% is set somewhere else.
If you have ideas, where to look, I may be able to provide the code to do it.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 29.11.2014, <01:17>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[cyg Simple]

On Fri, Nov 28, 2014 at 5:21 PM, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
>> On Nov 28 19:08, Andrey Repin wrote:
>>> > If we implement the above, we
>>> > would just have to add a cmd wrapper script in /bin to make sure
>>> > $PATH is set correctly and to make sure CMD starts up in $HOME,
>>> > something along the lines of:
>>>
>>> >   $ cat /bin/cmd
>>> >   #!/bin/dash
>>> >   PATH=/bin:$PATH
>>> >   cd $HOME
>>> >   # Don't rely on COMSPEC!
>>> >   cmd=$(cygpath -ua "${SYSTEMROOT}\\System32\\CMD.EXE")
>>> >   exec "${cmd}"
>>>
>>> I hope you don't expect it to work inside mintty.
>
>> Oh, it does.  CMD itself isn't the biggest problem, many other native
>> tools are.
>
> Yes, CMD itself do output... something. As long as encoding isn't an issue.
> But I have PROMPT=%USERNAME%%COMPUTERNAME%. Imagine if one of them turned out
> to contain non-ASCII characters.
>
>>> Cygwin tools may function
>>> properly in this case, but the shell itself - I have my doubts. And other
>>> native tools would certainly have issues with encoding, if not with any output
>>> at all.
>>> Said that, it would need to be a simple .cmd file, so that it'd run in native
>>> console.
>>> Something like
>>>
>>> @ECHO OFF
>>> PATH=%~dp0;%PATH%
>>> START "" /B "%SystemRoot%\System32\cmd.exe" /K
>>> EXIT
>
>> Fine with me, but it also has to cd to %HOME%, which is given in
>> POSIX syntax...
>
> That may be an issue, unless %HOME% is set somewhere else.
> If you have ideas, where to look, I may be able to provide the code to do it.
>

Don't forget that CMD will not create a second connection to a
\\host\share if Cygwin already has one open.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, cyg Simple!

> Don't forget that CMD will not create a second connection to a
> \\host\share if Cygwin already has one open.

What do you mean by that?


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 02.12.2014, <08:29>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[cyg Simple]

On Tue, Dec 2, 2014 at 12:29 AM, Andrey Repin wrote:
> Greetings, cyg Simple!
>
>> Don't forget that CMD will not create a second connection to a
>> \\host\share if Cygwin already has one open.
>
> What do you mean by that?

$ cd //somehost/someshare
$ cmd /c start cmd

cmd will complain about UNC paths and start in %WINDIR% instead.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, cyg Simple!

> On Tue, Dec 2, 2014 at 12:29 AM, Andrey Repin wrote:
>> Greetings, cyg Simple!
>>
>>> Don't forget that CMD will not create a second connection to a
>>> \\host\share if Cygwin already has one open.
>>
>> What do you mean by that?

> $ cd //somehost/someshare
> $ cmd /c start cmd

> cmd will complain about UNC paths and start in %WINDIR% instead.

That's why Windows mount homedir to a disk letter in first place.
But even if you choose the hard way, you can tell cmd to stop being ridiculous.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 03.12.2014, <23:09>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Linda Walsh]

Andrey Repin wrote:
> Greetings, cyg Simple!
>>>> Don't forget that CMD will not create a second connection to a
>>>> \\host\share if Cygwin already has one open.
>>> What do you mean by that?
> 
>> $ cd //somehost/someshare
>> $ cmd /c start cmd
> 
>> cmd will complain about UNC paths and start in %WINDIR% instead.
----
Try it the other way around.  You'll get the same result.

It has nothing to do with cygwin opening it first.  It has
to do with cmd not handling a "\\network\share" style address.

MS was too lazy to deal with command.com's "1-CurDir / drive"
scenario that is embedded in the Win32 interface.  If you cd to
//host/<currentdir>, //host isn't a drive letter.

So what happens when the user uses an absolute path?  "/tmp"...
where is that /tmp?   Ends up at the root of each drive, but on
a UNC-based-net-connection?  Undefined.  So cmd.exe can't be used
on a UNC-based path, only on DOS compatible (drive letter
assummed) based-path.




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Dec  4 04:20, Linda Walsh wrote:
> Andrey Repin wrote:
> >Greetings, cyg Simple!
> >>>>Don't forget that CMD will not create a second connection to a
> >>>>\\host\share if Cygwin already has one open.
> >>>What do you mean by that?
> >
> >>$ cd //somehost/someshare
> >>$ cmd /c start cmd
> >
> >>cmd will complain about UNC paths and start in %WINDIR% instead.
> ----
> Try it the other way around.  You'll get the same result.
> 
> It has nothing to do with cygwin opening it first.  It has
> to do with cmd not handling a "\\network\share" style address.
> 
> MS was too lazy to deal with command.com's "1-CurDir / drive"
> scenario that is embedded in the Win32 interface.  If you cd to
> //host/<currentdir>, //host isn't a drive letter.

It will get interesting with the new CMD from Windows 10.  MSFT has a
whole team now working on pulling CMD into the 21st century of CLIs.
Allowing UNC paths as CWD is apparently on their radar, though the
current latest CMD in the W10 preview is still missing this feature.

> So what happens when the user uses an absolute path?  "/tmp"...
> where is that /tmp?   Ends up at the root of each drive, but on
> a UNC-based-net-connection?  Undefined.  So cmd.exe can't be used
> on a UNC-based path, only on DOS compatible (drive letter
> assummed) based-path.

Allowing CMD as shell wouldn't change how Cygwin tools see the world.
Yes, with current CMDs you won't be able to utilize network paths as
CWD, among other restrictions.  Still, evaluating "db_shell: windows" as
using CMD, rather than being a no-op might hvae some value.  I would
never use it myself, but there may be some people, or, let's assume,
special maintainance accounts, for which this might come in handy.

Would it hurt to implement it, even only for symmetry with the other
options?  I'm not sure.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 28 13:48, Corinna Vinschen wrote:
> On Nov 28 15:08, Andrey Repin wrote:
> > Greetings, Corinna Vinschen!
> > 
> > >> The meaning of the schemata depend on the setting:
> > >> 
> > >>   db_home:
> > >> 
> > >>     windows         AD and SAM: Utilizes the setting of the homeDrive or
> > >>                   homeDirectory attributes, or their SAM "Home folder"
> > >>                   counterparts.  The Windows path is converted to a
> > >>                   POSIX path.
> > 
> > > I'm not really happy with this.  It requires to write some value to the
> > > homeDrive/homeDirectory attributes, because it doesn't fall back to the
> > > Windows default values.
> > 
> > > So, another question is this:  Shall "db_home: windows" fall back
> > > to the default Windows home dir if homeDrive/homeDirectory are empty?
> > 
> > Yes, if you mean it.
> > I mean, if you intend to use the same directory OS using for user's home
> > directory, you gotta use something that resembles the OS behavior.
> 
> Good point.  It's just a bit lengthy to implement.

Implemented in the latest snapshot at https://cygwin.com/snapshots/
Please give it a try.


Thanks,
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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>>   db_shell:
>> 
>>     windows         Ignored.  Do you want CMD instead?

> Would be interesting for symmetry only, I guess...

Adding to that: Cygwin shell is supposed to have access to Cygwin commands.
Running foreign shell may just get the user stuck in the middle of nowhere.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 28.11.2014, <15:23>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Cygwin AD integration home/shell changes

[Andrey Repin]

Greetings, Corinna Vinschen!

> Here's what you get:

I finally realized, what was tingling me all this time.
The implicit fallback mechanics. I'd rather want to have explicit declaration
and a failure message in case something isn't right. Much easier to fix system
issues, when the system tell you about them.
Shouldn't be a big change, considering you already have all the facilities in
order to make it works.

>   db_home:

>     windows         AD and SAM: Utilizes the setting of the homeDrive or
>                     homeDirectory attributes, or their SAM "Home folder"
>                     counterparts.  The Windows path is converted to a
>                     POSIX path.

>     cygwin          AD only: Shortcut for the cygwinHome attribute from
>                     the predefined cygwinUser auxiliary class.  POSIX path
>                     expected.

>     unix            AD only: Shortcut for the unixHomeDirectory attribute
>                     from the posixAccount auxiliary class.  POSIX path
>                     expected.

>     desc            AD and SAM: Fetch the home="..."
>                     setting from the user's description attribute.
>                     POSIX path expected.

>     @ad_attribute   AD-only: Read AD attribute "ad_attribute" as POSIX
>                     path.
>                     
>                     However, I'm contemplating to allow a Windows path
>                     here, too.  Does this make sense to you?

>     /path           POSIX path.  Remember the wildcards.

>     fallback        If nothing works, the fallback is /home/$USERNAME
>                     (Windows username).


>   db_shell:

>     windows         Ignored.  Do you want CMD instead?

>     cygwin          AD-only: Shortcut for the cygwinShell attribute
>                     from the cygwinUser class.  POSIX path.

>     unix            AD-only: Shortcut for the loginShell attribute
>                     from the posixAccount class.  POSIX path.

>     desc            AD and SAM: Fetch the shell="" setting from the
>                     user's description attribute.  POSIX path.

>     @ad_attribute   See above.

>     /path           See above.

>     fallback        If nothing works, the fallback is /bin/bash.


>   db_gecos:

>     windows         AD and SAM: displayName attribute, or "Full Name"
>                     setting in SAM. 

>     cygwin          AD-only: cygwinGecos attribute from cygwinUser class.

>     unix            AD-only: gecos attribute from posixAccount class.

>     @ad_attribute   Read AD attribute "ad_attribute" and prepend
>                     to pw_gecos.

>     /path           Skip the slash, prepend the reminder of the string
>                     to pw_gecos.  Note that the wildcards are still
>                     evaluated.

>     fallback        If nothing works, the fallback is no fallback.


> Examples:

>   db_home: cygwin desc

>     The default.  Try the cygwinHome attribute first. If it's empty,
>     evalaute the description field and see if the home dir is set via
>     the cygwin XML-style text.  If that fails, fallback is /home/$USERNAME
>     (Windows username).

>   db_home: unix @msTSHomeDirectory /home/%u

>     Try the unixHomeDirectory attribute first.  Empty?  Try the
>     (otherwise unused) msTSHomeDirectory attribute.  Empty?  Fall back
>     to /home/$USER (Cygwin username).

>   db_gecos: @comment /Hallo%_%U

>     Try the comment attribute.  Empty?  Fall back to the string
>     "Hallo <Windows username>".  Example passwd entry:

>       corinna:*:1049577:1049701:Hallo
> corinna,U-MY_DOM\corinna,S-1-5-21-yada-yada:/home/corinna:/bin/bash

> Is this new stuff basically clear?  Questions?

> Please give it a try.


> Thanks,
> Corinna



--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 03.12.2014, <10:11>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin AD integration home/shell changes

[Corinna Vinschen]

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

On Dec  3 10:26, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > Here's what you get:
> 
> I finally realized, what was tingling me all this time.
> The implicit fallback mechanics. I'd rather want to have explicit declaration
> and a failure message in case something isn't right. Much easier to fix system
> issues, when the system tell you about them.

The fallback mechanism is pretty much required to have a sane default
which works for home users without having to change nsswitch.conf at
all.  Also, not everybody will want error messages rather than some sane
fallback (for any given value of "sane"), while if you don't want a sane
fallback, you can easily create an unsane fallback to help you maintain
your solution, e.g.

  db_home: cygwin /invalid/read-only-path


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 --]

Re: Cygwin AD integration home/shell changes

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > Here's what you get:
>> 
>> I finally realized, what was tingling me all this time.
>> The implicit fallback mechanics. I'd rather want to have explicit declaration
>> and a failure message in case something isn't right. Much easier to fix system
>> issues, when the system tell you about them.

> The fallback mechanism is pretty much required to have a sane default
> which works for home users without having to change nsswitch.conf at
> all.  Also, not everybody will want error messages rather than some sane
> fallback (for any given value of "sane"), while if you don't want a sane
> fallback, you can easily create an unsane fallback to help you maintain
> your solution, e.g.

>   db_home: cygwin /invalid/read-only-path

Why not set defaults (in case of db_home) to

db_home: cygwin desc /home/%U

and remove fallback?
It just not seems right - creating workarounds to implement straight behavior.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 03.12.2014, <16:39>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin AD integration home/shell changes

[Corinna Vinschen]

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

On Dec  3 16:44, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> > Here's what you get:
> >> 
> >> I finally realized, what was tingling me all this time.
> >> The implicit fallback mechanics. I'd rather want to have explicit declaration
> >> and a failure message in case something isn't right. Much easier to fix system
> >> issues, when the system tell you about them.
> 
> > The fallback mechanism is pretty much required to have a sane default
> > which works for home users without having to change nsswitch.conf at
> > all.  Also, not everybody will want error messages rather than some sane
> > fallback (for any given value of "sane"), while if you don't want a sane
> > fallback, you can easily create an unsane fallback to help you maintain
> > your solution, e.g.
> 
> >   db_home: cygwin /invalid/read-only-path
> 
> Why not set defaults (in case of db_home) to
> 
> db_home: cygwin desc /home/%U
> 
> and remove fallback?
> It just not seems right - creating workarounds to implement straight behavior.

It's not a workaround from my POV to provide a fallback.  Creating a
workable passwd entry is important.  If I implement it as you suggest
above, I would still provide the typical "set home to the root dir"
default.  Sure, that might be an option.


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 --]

Re: Cygwin AD integration home/shell changes

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> > Here's what you get:
>> >> 
>> >> I finally realized, what was tingling me all this time.
>> >> The implicit fallback mechanics. I'd rather want to have explicit declaration
>> >> and a failure message in case something isn't right. Much easier to fix system
>> >> issues, when the system tell you about them.
>> 
>> > The fallback mechanism is pretty much required to have a sane default
>> > which works for home users without having to change nsswitch.conf at
>> > all.  Also, not everybody will want error messages rather than some sane
>> > fallback (for any given value of "sane"), while if you don't want a sane
>> > fallback, you can easily create an unsane fallback to help you maintain
>> > your solution, e.g.
>> 
>> >   db_home: cygwin /invalid/read-only-path
>> 
>> Why not set defaults (in case of db_home) to
>> 
>> db_home: cygwin desc /home/%U
>> 
>> and remove fallback?
>> It just not seems right - creating workarounds to implement straight behavior.

> It's not a workaround from my POV to provide a fallback.  Creating a
> workable passwd entry is important.  If I implement it as you suggest
> above, I would still provide the typical "set home to the root dir"
> default.  Sure, that might be an option.

If you mean "complain and set home to the root", then I'm happy with this
solution.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 05.12.2014, <08:06>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin AD integration home/shell changes

[Corinna Vinschen]

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

On Dec  5 08:07, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> >> > Here's what you get:
> >> >> 
> >> >> I finally realized, what was tingling me all this time.
> >> >> The implicit fallback mechanics. I'd rather want to have explicit declaration
> >> >> and a failure message in case something isn't right. Much easier to fix system
> >> >> issues, when the system tell you about them.
> >> 
> >> > The fallback mechanism is pretty much required to have a sane default
> >> > which works for home users without having to change nsswitch.conf at
> >> > all.  Also, not everybody will want error messages rather than some sane
> >> > fallback (for any given value of "sane"), while if you don't want a sane
> >> > fallback, you can easily create an unsane fallback to help you maintain
> >> > your solution, e.g.
> >> 
> >> >   db_home: cygwin /invalid/read-only-path
> >> 
> >> Why not set defaults (in case of db_home) to
> >> 
> >> db_home: cygwin desc /home/%U
> >> 
> >> and remove fallback?
> >> It just not seems right - creating workarounds to implement straight behavior.
> 
> > It's not a workaround from my POV to provide a fallback.  Creating a
> > workable passwd entry is important.  If I implement it as you suggest
> > above, I would still provide the typical "set home to the root dir"
> > default.  Sure, that might be an option.
> 
> If you mean "complain and set home to the root", then I'm happy with this
> solution.

No complain.  You still seem to have a problem to understand that this
is underlying functionality under a couple of system calls generating
passwd entries for arbitrary accounts.  It's *not* necessarily the
current account.  A user visible complaint for every unconfigured account
enumerated via getpwent is quite over the top.


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 --]

Re: Cygwin AD integration home/shell changes

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> >> > Here's what you get:
>> >> >> 
>> >> >> I finally realized, what was tingling me all this time.
>> >> >> The implicit fallback mechanics. I'd rather want to have explicit declaration
>> >> >> and a failure message in case something isn't right. Much easier to fix system
>> >> >> issues, when the system tell you about them.
>> >> 
>> >> > The fallback mechanism is pretty much required to have a sane default
>> >> > which works for home users without having to change nsswitch.conf at
>> >> > all.  Also, not everybody will want error messages rather than some sane
>> >> > fallback (for any given value of "sane"), while if you don't want a sane
>> >> > fallback, you can easily create an unsane fallback to help you maintain
>> >> > your solution, e.g.
>> >> 
>> >> >   db_home: cygwin /invalid/read-only-path
>> >> 
>> >> Why not set defaults (in case of db_home) to
>> >> 
>> >> db_home: cygwin desc /home/%U
>> >> 
>> >> and remove fallback?
>> >> It just not seems right - creating workarounds to implement straight behavior.
>> 
>> > It's not a workaround from my POV to provide a fallback.  Creating a
>> > workable passwd entry is important.  If I implement it as you suggest
>> > above, I would still provide the typical "set home to the root dir"
>> > default.  Sure, that might be an option.
>> 
>> If you mean "complain and set home to the root", then I'm happy with this
>> solution.

> No complain.  You still seem to have a problem to understand that this
> is underlying functionality under a couple of system calls generating
> passwd entries for arbitrary accounts.

> It's *not* necessarily the current account.  A user visible complaint for
> every unconfigured account enumerated via getpwent is quite over the top.

No, I perfectly understand it. The sooner I get slapped in the face with
a printout of my incorrect and intolerable settings, the better.

I do understand, that the settings MUST provide at least one sensible result.
Assuming we get sensible defaults, this will not be an issue for majority of
people.
However, for those, who wish to alter the setting, it is better, if they get a
slap this instant, if the setting is not quite right, rather than if they
discover issue after a long time is passed.
Issues with core configuration should not be masked by obscure defaults. IMHO.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 05.12.2014, <21:41>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin AD integration home/shell changes

[Corinna Vinschen]

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

On Dec  5 23:11, Andrey Repin wrote:
> I do understand, that the settings MUST provide at least one sensible result.
> Assuming we get sensible defaults, this will not be an issue for majority of
> people.
> However, for those, who wish to alter the setting, it is better, if they get a
> slap this instant, if the setting is not quite right, rather than if they
> discover issue after a long time is passed.
> Issues with core configuration should not be masked by obscure defaults. IMHO.

"Obscure"?  /home/<username> is the fallback for a long time.
mkpasswd creates it these days.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 26 21:56, Corinna Vinschen wrote:
> On Nov 11 12:14, Corinna Vinschen wrote:
> > On Nov 11 11:05, Achim Gratz wrote:
> > > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
> > > >   the above:
> > > > 
> > > >     home: [unix|win|home]...
> > > > 
> > > >    - "unix" means, set pw_dir to unixHomeDirectory
> > > >    - "win" means, set pw_dir to homeDirectory
> > > >    - "home" means, set pw_dir to /home/$USER
> > > >    - Multiple entries are possible.
> > > >    - Default in the absence of this setting is: always set pw_dir to
> > > >      /home/$USER.
> > > 
> > > Looks good, but maybe allow the AD attribute to be explicitly named (e.g.
> > > cygwinHomeDirectory).
> > 
> > Cygwin schema extension? :)
> 
> I just created a patch and a matching snapshot on
> https://cygwin.com/snapshots/
> 
> The new stuff is still missing documentation, [...]

If you're wondering why I didn't create a test release yet, it's all
about this dreaded documentation.

Did I mention already how much I hate writing documentation?  Yes?
Whatever.  I really hate writing documentation!  It's infinitely worse
than writing the code.

I'm just working on the documentation and it's going forward really
tenaciously, so I felt the need to vent^Wkeep you informed.

When I have a more or less working piece of documentation, I'll create 
a new Cygwin test release again, for installation via setup.

I'd appreciate if those not shy to install developer snapshots would
give this stuff a try in the meantime.

Also, if you don't understand the settings, or some of the settings,
feel free to ask.  The developer (that's me, I guess) sometimes just
doesn't know if the description makes sense or not.  It will very likely
help to make the documentation better.


Thanks,
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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> On Nov 11 12:14, Corinna Vinschen wrote:
>> > On Nov 11 11:05, Achim Gratz wrote:
>> > > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
>> > > > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
>> > > >   the above:
>> > > > 
>> > > >     home: [unix|win|home]...
>> > > > 
>> > > >    - "unix" means, set pw_dir to unixHomeDirectory
>> > > >    - "win" means, set pw_dir to homeDirectory
>> > > >    - "home" means, set pw_dir to /home/$USER
>> > > >    - Multiple entries are possible.
>> > > >    - Default in the absence of this setting is: always set pw_dir to
>> > > >      /home/$USER.
>> > > 
>> > > Looks good, but maybe allow the AD attribute to be explicitly named (e.g.
>> > > cygwinHomeDirectory).
>> > 
>> > Cygwin schema extension? :)
>> 
>> I just created a patch and a matching snapshot on
>> https://cygwin.com/snapshots/
>> 
>> The new stuff is still missing documentation, [...]

> If you're wondering why I didn't create a test release yet, it's all
> about this dreaded documentation.

> Did I mention already how much I hate writing documentation?  Yes?
> Whatever.  I really hate writing documentation!  It's infinitely worse
> than writing the code.

Every 10 lines of documentation I write for my projects make me want to
rewrite at least one line of the code. Because it feels stupid now, that I've
explained, how it works.

> I'm just working on the documentation and it's going forward really
> tenaciously, so I felt the need to vent^Wkeep you informed.

> When I have a more or less working piece of documentation, I'll create 
> a new Cygwin test release again, for installation via setup.

> I'd appreciate if those not shy to install developer snapshots would
> give this stuff a try in the meantime.

I think I'm about to make a script to install snapshots, at this rate it seems
the right thing to do.
Is there a direct way to query for the latest snapshot?
I'm not very fond of HTML parsing.

> Also, if you don't understand the settings, or some of the settings,
> feel free to ask.  The developer (that's me, I guess) sometimes just
> doesn't know if the description makes sense or not.  It will very likely
> help to make the documentation better.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 05.12.2014, <08:16>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Dec  5 08:28, Andrey Repin wrote:
> >> On Nov 11 12:14, Corinna Vinschen wrote:
> >> The new stuff is still missing documentation, [...]
> 
> > If you're wondering why I didn't create a test release yet, it's all
> > about this dreaded documentation.
> 
> > Did I mention already how much I hate writing documentation?  Yes?
> > Whatever.  I really hate writing documentation!  It's infinitely worse
> > than writing the code.
> 
> Every 10 lines of documentation I write for my projects make me want to
> rewrite at least one line of the code. Because it feels stupid now, that I've
> explained, how it works.

Unfortunately you *have* to explain configuration.

> > I'd appreciate if those not shy to install developer snapshots would
> > give this stuff a try in the meantime.
> 
> I think I'm about to make a script to install snapshots, at this rate it seems
> the right thing to do.
> Is there a direct way to query for the latest snapshot?

The snapshots always have a date attached to the filename.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > I'd appreciate if those not shy to install developer snapshots would
>> > give this stuff a try in the meantime.
>> 
>> I think I'm about to make a script to install snapshots, at this rate it seems
>> the right thing to do.
>> Is there a direct way to query for the latest snapshot?

> The snapshots always have a date attached to the filename.

I mean, if there's a way to know, what is the latest available snapshot?
If I want to write a script, that fetch [and install] one.
I can parse the /snapshots/ page, of course, but this is the least desirable
choice. For multiple reasons. I would like to have a single point, that could
refer to the very latest snapshot. Even if it is something like
/snapshots/x86/cygwin-inst-latest.tar.xz redirecting to
actual latest snapshot, that'd be quite enough.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 05.12.2014, <23:12>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Dec  6 00:05, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> > I'd appreciate if those not shy to install developer snapshots would
> >> > give this stuff a try in the meantime.
> >> 
> >> I think I'm about to make a script to install snapshots, at this rate it seems
> >> the right thing to do.
> >> Is there a direct way to query for the latest snapshot?
> 
> > The snapshots always have a date attached to the filename.
> 
> I mean, if there's a way to know, what is the latest available snapshot?
> If I want to write a script, that fetch [and install] one.
> I can parse the /snapshots/ page, of course, but this is the least desirable
> choice. For multiple reasons. I would like to have a single point, that could
> refer to the very latest snapshot. Even if it is something like
> /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to
> actual latest snapshot, that'd be quite enough.

http://cygwin.com/acronyms/#SHTDI
http://cygwin.com/acronyms/#PGA


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[cyg Simple]

On Fri, Dec 5, 2014 at 4:05 PM, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
>>> > I'd appreciate if those not shy to install developer snapshots would
>>> > give this stuff a try in the meantime.
>>>
>>> I think I'm about to make a script to install snapshots, at this rate it seems
>>> the right thing to do.
>>> Is there a direct way to query for the latest snapshot?
>
>> The snapshots always have a date attached to the filename.
>
> I mean, if there's a way to know, what is the latest available snapshot?
> If I want to write a script, that fetch [and install] one.
> I can parse the /snapshots/ page, of course, but this is the least desirable
> choice. For multiple reasons. I would like to have a single point, that could
> refer to the very latest snapshot. Even if it is something like
> /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to
> actual latest snapshot, that'd be quite enough.
>

You could just parse the setup.hint file from your favorite mirror.

test: cygwin-1.7.34-002

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, cyg Simple!

> On Fri, Dec 5, 2014 at 4:05 PM, Andrey Repin wrote:
>> Greetings, Corinna Vinschen!
>>
>>>> > I'd appreciate if those not shy to install developer snapshots would
>>>> > give this stuff a try in the meantime.
>>>>
>>>> I think I'm about to make a script to install snapshots, at this rate it seems
>>>> the right thing to do.
>>>> Is there a direct way to query for the latest snapshot?
>>
>>> The snapshots always have a date attached to the filename.
>>
>> I mean, if there's a way to know, what is the latest available snapshot?
>> If I want to write a script, that fetch [and install] one.
>> I can parse the /snapshots/ page, of course, but this is the least desirable
>> choice. For multiple reasons. I would like to have a single point, that could
>> refer to the very latest snapshot. Even if it is something like
>> /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to
>> actual latest snapshot, that'd be quite enough.
>>

> You could just parse the setup.hint file from your favorite mirror.

> test: cygwin-1.7.34-002

Thanks for suggestion, but test release =/= snapshot[1].

[1] http://cygwin.com/snapshots/


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 11.12.2014, <01:41>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[David Stacey]

On 10/12/14 20:52, cyg Simple wrote:
> On Fri, Dec 5, 2014 at 4:05 PM, Andrey Repin wrote:
>> Greetings, Corinna Vinschen!
>>
>>>>> I'd appreciate if those not shy to install developer snapshots would
>>>>> give this stuff a try in the meantime.
>>>> I think I'm about to make a script to install snapshots, at this rate it seems
>>>> the right thing to do.
>>>> Is there a direct way to query for the latest snapshot?
>>
>>>   The snapshots always have a date attached to the filename.
>> I mean, if there's a way to know, what is the latest available snapshot?
>> If I want to write a script, that fetch [and install] one.
>> I can parse the/snapshots/  page, of course, but this is the least desirable
>> choice. For multiple reasons. I would like to have a single point, that could
>> refer to the very latest snapshot. Even if it is something like
>> /snapshots/x86/cygwin-inst-latest.tar.xz redirecting to
>> actual latest snapshot, that'd be quite enough.
>>
> You could just parse the setup.hint file from your favorite mirror.

This doesn't work in the general case, as not all snapshots are uploaded 
as test packages. Plus you'd have to wait while your favourite mirror 
picked up the new package.

Sadly, parsing the HTML is the only way to go right now. This is very 
error-prone, as any assumption you make about the structure of the HTML 
could change with no notice. The following works (as the snapshots page 
stands) by extracting the date from one of the filenames:

wget -q -O - http://cygwin.com/snapshots/ | egrep 
"cygwin1-[0-9]*.dll.xz" | head -n 1 | sed 
's/^.*cygwin1-\([0-9]*\)\.dll\.xz.*$/\1/g'

This is about as fool-proof as I can make it. It assumes nothing about 
the HTML, so it should survive a fairly substantial change to the web 
page. Provided we don't change the format of the filenames, the above 
stands a chance of working. YMMV.

Cheers,

Dave.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 11 11:18, Corinna Vinschen wrote:
> On Nov 10 23:09, Warren Young wrote:
> > On Nov 10, 2014, at 1:52 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> > 
> > > Shall the "db" entries utilize the Windows home folder if it exits(*)
> > > and drop using the unixHomeDirectory?  It seems inevitable…
> > 
> > Use of AD implies some level of security consciousness.  The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator.
> > 
> > This answer I wrote on Stack Overflow is one way to solve the problem today:
> > 
> >     http://stackoverflow.com/questions/26666180/
> > 
> > It might not be a bad idea if Cygwin started doing this sort of thing by default in the future.  (Obviously for new installs only.)
> 
> What I gather from the replies so far is this:
> 
> - Nobody really cares for unixHomeDirectory.
> 
> - Some want to use the Windows home folder.
> 
> - Some want Cygwin to utilize the HOMEPATH dir.
> 
> - Some want Cygwin to use always it's own /home and do everything else
>   via symlinks or mount points.
> 
> The problem so far is that I'm not sure it's clear to everybody what
> I mean.  I'm *not* talking about a default value which can easily be
> overridden by tweaking /etc/passwd.  I'm talking about what the passwd
> entry contains if there's no passwd file, and the admins want to keep
> the administration strictly inside AD.  The passwd entry gets generated
> from what AD provides.  And here we need a sensible default behaviour.
> 
> One possible, but not naturally useful default behaviour is what
> the current code does:
> 
> 1. Utilize the unixHomeDirectory AD attribute.
> 2. If unixHomeDirectory is empty, fall back to /home/$USER.
> 
> Another possible behaviour:
> 
> 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%).
> 2. If homeDirectory is empty, fall back to /home/$USER.
> 
> Another:
> 
> 1. Always use /home/$USER and let the admins come up with a matching
>    mount point scheme.
> 
> Another:
> 
> 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
>   the above:
> 
>     home: [unix|win|home]...
> 
>    - "unix" means, set pw_dir to unixHomeDirectory
>    - "win" means, set pw_dir to homeDirectory
>    - "home" means, set pw_dir to /home/$USER
>    - Multiple entries are possible.
>    - Default in the absence of this setting is: always set pw_dir to
>      /home/$USER.

Another way to handle Cygwin-specific settings would be to utilize the
description(*) field in the user's entry, just as implemented for SAM
accounts.  See the SAM part of
https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo
for how to use XML-alike entries in the description field to add user
data, for instance

  <cygwin home="/foo/bar"\ shell="/bin/tcsh"/>

This could be added to some standard scheme:

  1. Utilize the description attribute.
  2. If description is empty, utilize homeDirectory.
  3. If homeDirectory is empty, use /home/$USER.

Or this could be added as a setting in nsswitch.conf:

  home: [unix|win|desc|home]

I could think of arbitrarily complex ways to extend this nsswitch.conf
setting, as in:

  home: /foo/bar/%U

With %U being the Windows username, %D the domain name, %u the Cygwin
user name.  But all this also takes time to implement, of course :(


Corinna


(*) Note the naming confusion:
    The `net user /comment:...' command sets the AD attribute "description".
    The `net user /usercomment:...' command sets the AD attribute "comment".

-- 
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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Bryan Berns]

One big vote for the '/etc/nsswitch.conf' idea.  I think the truth of
the matter is that enterprise environments are way too dynamic (and
inconsistent) to attempt to satisfy the majority of configurations
with any particular default ordering assumption.

Another user brought up a good point about desire for Cygwin to
operate in 'read-only' mode -- something that I'd also really love to
see addressed.  The need for /tmp and /var/log to be 'writable'
results in some problems in a high-security environments.  This became
especially noticeable with Cygwin 64-bit because Windows does not
automatically redirect write attempts to %LOCALAPPDATA%\VirtualStore.
Anyhow, that's probably left to a different conversation for a
different day...

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 11 07:11, Bryan Berns wrote:
> One big vote for the '/etc/nsswitch.conf' idea.  I think the truth of
> the matter is that enterprise environments are way too dynamic (and
> inconsistent) to attempt to satisfy the majority of configurations
> with any particular default ordering assumption.
> 
> Another user brought up a good point about desire for Cygwin to
> operate in 'read-only' mode -- something that I'd also really love to
> see addressed.  The need for /tmp and /var/log to be 'writable'
> results in some problems in a high-security environments.

This can be easily fixed by providing matching mount points in
/etc/fstab or /etc/fstab.d.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > Shall the "db" entries utilize the Windows home folder if it exits(*)
>> > and drop using the unixHomeDirectory?  It seems inevitable…
>> 
>> Use of AD implies some level of security consciousness.  The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator.
>> 
>> This answer I wrote on Stack Overflow is one way to solve the problem today:
>> 
>>     http://stackoverflow.com/questions/26666180/
>> 
>> It might not be a bad idea if Cygwin started doing this sort of thing by default in the future.  (Obviously for new installs only.)

> What I gather from the replies so far is this:

> - Nobody really cares for unixHomeDirectory.

As I understand it from replies, it's not "nobody care", it's "this is wrong
way of doing it".

> - Some want to use the Windows home folder.

> - Some want Cygwin to utilize the HOMEPATH dir.

When you clarify your question, this seems to be the same point.

> - Some want Cygwin to use always it's own /home and do everything else
>   via symlinks or mount points.

> The problem so far is that I'm not sure it's clear to everybody what
> I mean.  I'm *not* talking about a default value which can easily be
> overridden by tweaking /etc/passwd.  I'm talking about what the passwd
> entry contains if there's no passwd file, and the admins want to keep
> the administration strictly inside AD.  The passwd entry gets generated
> from what AD provides.  And here we need a sensible default behaviour.

Yes, this makes more sense.

> One possible, but not naturally useful default behaviour is what
> the current code does:

> 1. Utilize the unixHomeDirectory AD attribute.
> 2. If unixHomeDirectory is empty, fall back to /home/$USER.

As has been pointed out, unixHomeDirectory is to tell *NIX system, where o
look for user's homedir. Cygwin is not a a Unix system, and I have to agree
that using this attribute for Cygwin wouldn't be the right thing.

> Another possible behaviour:

> 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%).
> 2. If homeDirectory is empty, fall back to /home/$USER.

> Another:

> 1. Always use /home/$USER and let the admins come up with a matching
>    mount point scheme.

> Another:

> 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
>   the above:

>     home: [unix|win|home]...

>    - "unix" means, set pw_dir to unixHomeDirectory
>    - "win" means, set pw_dir to homeDirectory
>    - "home" means, set pw_dir to /home/$USER
>    - Multiple entries are possible.
>    - Default in the absence of this setting is: always set pw_dir to
>      /home/$USER.

How about a slight modification to this?

nsswitch.conf configurable settings:
user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different
platform Cygwins)
system: Use homeDirectory AD attribute.
cygwin: Use current Cygwin way of /home/$USERNAME.

Default setting is up to discussion.

This is more clear in my opinon, than "unix" or "win" (Cygwin is not
"unix/linux", neither it's "windows" - it's a userspace DLL providing POSIX
API compatibility in Windows), and definitely more clear, than "home: home".


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 11.11.2014, <18:18>

Sorry for my terrible english...

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 11 18:29, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> > Shall the "db" entries utilize the Windows home folder if it exits(*)
> >> > and drop using the unixHomeDirectory?  It seems inevitable…
> >> 
> >> Use of AD implies some level of security consciousness.  The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator.
> >> 
> >> This answer I wrote on Stack Overflow is one way to solve the problem today:
> >> 
> >>     http://stackoverflow.com/questions/26666180/
> >> 
> >> It might not be a bad idea if Cygwin started doing this sort of thing by default in the future.  (Obviously for new installs only.)
> 
> > What I gather from the replies so far is this:
> 
> > - Nobody really cares for unixHomeDirectory.
> 
> As I understand it from replies, it's not "nobody care", it's "this is wrong
> way of doing it".

It's not the wrong thing if it's not used for anything else in a
company.

> > Another:
> 
> > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
> >   the above:
> 
> >     home: [unix|win|home]...
> 
> >    - "unix" means, set pw_dir to unixHomeDirectory
> >    - "win" means, set pw_dir to homeDirectory
> >    - "home" means, set pw_dir to /home/$USER
> >    - Multiple entries are possible.
> >    - Default in the absence of this setting is: always set pw_dir to
> >      /home/$USER.
> 
> How about a slight modification to this?
> 
> nsswitch.conf configurable settings:
> user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different
> platform Cygwins)

I really don't like this one.  Your naming scheme (user/system/cygwin)
has its merits, but I don't see that a home directory of any sort
belongs under AppData.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> > Shall the "db" entries utilize the Windows home folder if it exits(*)
>> >> > and drop using the unixHomeDirectory?  It seems inevitable…
>> >> 
>> >> Use of AD implies some level of security consciousness.  The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator.
>> >> 
>> >> This answer I wrote on Stack Overflow is one way to solve the problem today:
>> >> 
>> >>     http://stackoverflow.com/questions/26666180/
>> >> 
>> >> It might not be a bad idea if Cygwin started doing this sort of thing by default in the future.  (Obviously for new installs only.)
>> 
>> > What I gather from the replies so far is this:
>> 
>> > - Nobody really cares for unixHomeDirectory.
>> 
>> As I understand it from replies, it's not "nobody care", it's "this is wrong
>> way of doing it".

> It's not the wrong thing if it's not used for anything else in a
> company.

I would step away from any possible if's as much as... possible in such case.

>> > Another:
>> 
>> > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
>> >   the above:
>> 
>> >     home: [unix|win|home]...
>> 
>> >    - "unix" means, set pw_dir to unixHomeDirectory
>> >    - "win" means, set pw_dir to homeDirectory
>> >    - "home" means, set pw_dir to /home/$USER
>> >    - Multiple entries are possible.
>> >    - Default in the absence of this setting is: always set pw_dir to
>> >      /home/$USER.
>> 
>> How about a slight modification to this?
>> 
>> nsswitch.conf configurable settings:
>> user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different
>> platform Cygwins)

> I really don't like this one.

I'm just summing up suggestions that have been raised in the list for last
day. :)

> Your naming scheme (user/system/cygwin) has its merits, but I don't see that
> a home directory of any sort belongs under AppData.

Not home directory. User profile directory.
https://cygwin.com/ml/cygwin/2014-11/msg00201.html

%AppData%/Cygwin == %HOMEPATH%/AppData/Roaming/Cygwin

From corporate environment point of view, Cygwin is an application like every
other one, and expected to behave according to environment standards, not
invent its own. Windows environment standard dictates, that if an application
intend to store large amount of user-specific files, it should do so uder
%AppData%, or %LocalAppData% for discardable or hardware-specific environment.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 11.11.2014, <23:01>

Sorry for my terrible english...

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 11 23:19, Andrey Repin wrote:
> >> nsswitch.conf configurable settings:
> >> user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different
> >> platform Cygwins)
> 
> > I really don't like this one.
> 
> I'm just summing up suggestions that have been raised in the list for last
> day. :)
> 
> > Your naming scheme (user/system/cygwin) has its merits, but I don't see that
> > a home directory of any sort belongs under AppData.
> 
> Not home directory. User profile directory.
> https://cygwin.com/ml/cygwin/2014-11/msg00201.html

I was talking about the Cygwin home dir.  The home dir is a home dir.
It doesn't contain only stuff which is application dependent.  It may
also contain arbitrary user-specific stuff.  So the Cygwin home dir
is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%,
not %HOMEPATH%/AppData/Roaming/CMD.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> nsswitch.conf configurable settings:
>> >> user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different
>> >> platform Cygwins)
>> 
>> > I really don't like this one.
>> 
>> I'm just summing up suggestions that have been raised in the list for last
>> day. :)
>> 
>> > Your naming scheme (user/system/cygwin) has its merits, but I don't see that
>> > a home directory of any sort belongs under AppData.
>> 
>> Not home directory. User profile directory.
>> https://cygwin.com/ml/cygwin/2014-11/msg00201.html

> I was talking about the Cygwin home dir.  The home dir is a home dir.
> It doesn't contain only stuff which is application dependent.

We know that much. But it isn't easy to convince whole world in this truth.

> It may
> also contain arbitrary user-specific stuff.

Cygwin-user specific, I'd say. At least, that seems to be common expectation
among the users and developers here.

> So the Cygwin home dir
> is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%,

Which is covered by "system" setting. Which will either read the location from
AD or use %HOMEPATH%, if all else fails.

> not %HOMEPATH%/AppData/Roaming/CMD.

I don't see, why not. Forget for a moment about its true location.
Does it matter, where the files are located, when cygwin is running?


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 12.11.2014, <23:18>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 12 23:23, Andrey Repin wrote:
> > So the Cygwin home dir
> > is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%,
> 
> Which is covered by "system" setting. Which will either read the location from
> AD or use %HOMEPATH%, if all else fails.
> 
> > not %HOMEPATH%/AppData/Roaming/CMD.
> 
> I don't see, why not. Forget for a moment about its true location.
> Does it matter, where the files are located, when cygwin is running?

Not when it's running, but a homedir does *not* belong under AppData,
especially not under Roaming.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

> On Nov 12 23:23, Andrey Repin wrote:
>> > So the Cygwin home dir
>> > is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%,
>> 
>> Which is covered by "system" setting. Which will either read the location from
>> AD or use %HOMEPATH%, if all else fails.
>> 
>> > not %HOMEPATH%/AppData/Roaming/CMD.
>> 
>> I don't see, why not. Forget for a moment about its true location.
>> Does it matter, where the files are located, when cygwin is running?

> Not when it's running, but a homedir does *not* belong under AppData,
> especially not under Roaming.

Perhaps, I'm missing something. What meaning exactly you put into "homedir",
which seems to preclude any possibility of discussion?


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 14.11.2014, <00:47>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 14 00:49, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > On Nov 12 23:23, Andrey Repin wrote:
> >> > So the Cygwin home dir
> >> > is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%,
> >> 
> >> Which is covered by "system" setting. Which will either read the location from
> >> AD or use %HOMEPATH%, if all else fails.
> >> 
> >> > not %HOMEPATH%/AppData/Roaming/CMD.
> >> 
> >> I don't see, why not. Forget for a moment about its true location.
> >> Does it matter, where the files are located, when cygwin is running?
> 
> > Not when it's running, but a homedir does *not* belong under AppData,
> > especially not under Roaming.
> 
> Perhaps, I'm missing something. What meaning exactly you put into "homedir",
> which seems to preclude any possibility of discussion?

You apparently didn't read what I wrote in this thread.  AppData is the
wrong spot.  Applications are not supposed to use AppData directly,
rather just the subfolders.  And the Roaming subfolder is the worst
of all, given that it contains the roaming profile, which is copied
over to the client at login time.  This is not at all the place for
any kind of home directory.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> > So the Cygwin home dir
>> >> > is equivalent to the CMD homedir, which is %HOMEDRIVE%%HOMEPATH%,
>> >> 
>> >> Which is covered by "system" setting. Which will either read the location from
>> >> AD or use %HOMEPATH%, if all else fails.
>> >> 
>> >> > not %HOMEPATH%/AppData/Roaming/CMD.
>> >> 
>> >> I don't see, why not. Forget for a moment about its true location.
>> >> Does it matter, where the files are located, when cygwin is running?
>> 
>> > Not when it's running, but a homedir does *not* belong under AppData,
>> > especially not under Roaming.
>> 
>> Perhaps, I'm missing something. What meaning exactly you put into "homedir",
>> which seems to preclude any possibility of discussion?

> You apparently didn't read what I wrote in this thread.  AppData is the
> wrong spot.  Applications are not supposed to use AppData directly,
> rather just the subfolders.

I didn't suggest to use AppData directly >.<

> And the Roaming subfolder is the worst
> of all, given that it contains the roaming profile, which is copied
> over to the client at login time.  This is not at all the place for
> any kind of home directory.

Well, now, this is an argument I won't be arguing about.
Any expectations of size of a file or directory have a tendency to be wrong.
(Proved by passwd/group files...)



--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 17.11.2014, <06:49>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Warren Young]

On Nov 11, 2014, at 3:18 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

> 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%).
> 2. If homeDirectory is empty, fall back to /home/$USER.

This is just a subset of what I suggested, so I’m in favor of it.

(By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.)

> 1. Always use /home/$USER and let the admins come up with a matching
>   mount point scheme.

That’s neglecting your responsibility as BDFL to set a sensible default.  The consequence is that everyone will do it differently, and then you’ll have to support everything on an equal basis, because you chose not to endorse anything.

When you choose a sensible default, you get the option to criticize and even deprecate wild alternative schemes.

> 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
>  the above:
> 
>    home: [unix|win|home]...
> 
>   - "unix" means, set pw_dir to unixHomeDirectory
>   - "win" means, set pw_dir to homeDirectory
>   - "home" means, set pw_dir to /home/$USER
>   - Multiple entries are possible.
>   - Default in the absence of this setting is: always set pw_dir to
>     /home/$USER.

I see that as orthogonal.  It has the advantage of providing not only a sensible default but also a list of endorsed alternatives.

Whether you *want* to endorse some or all of these alternatives by codifying them is a separate question.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 12 09:45, Warren Young wrote:
> On Nov 11, 2014, at 3:18 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> > 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%).
> > 2. If homeDirectory is empty, fall back to /home/$USER.
> 
> This is just a subset of what I suggested, so I’m in favor of it.
> (By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.)

This would be most easily implemented as well.

The beauty here is that probably 99% of the home users don't set
HOMEDRIVE/HOMEPATH in their SAM.  So they get /home/$USER as fallback,
which is what they got with /etc/passwd as well.  And SAM users have the
XML-like description field entry as well.

For AD environments HOMEDRIVE/HOMEPATH are typically set, though.
Here the users get what they have to use as homedir anyway.

It's simple, but it should work OOTB for most people.

> > 1. Always use /home/$USER and let the admins come up with a matching
> >   mount point scheme.
> 
> That’s neglecting your responsibility as BDFL to set a sensible

Heh.  I didn't see myself as BDFL yet.  Not sure if that's an honor.

> default.  The consequence is that everyone will do it differently, and
> then you’ll have to support everything on an equal basis, because you
> chose not to endorse anything.
> 
> When you choose a sensible default, you get the option to criticize
> and even deprecate wild alternative schemes.

This is a philosophical argument.  You'd have to argue in how far
always using /home/$USER is NOT a sensible default.

> > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of
> >  the above:
> > 
> >    home: [unix|win|home]...
> > 
> >   - "unix" means, set pw_dir to unixHomeDirectory
> >   - "win" means, set pw_dir to homeDirectory
> >   - "home" means, set pw_dir to /home/$USER
> >   - Multiple entries are possible.
> >   - Default in the absence of this setting is: always set pw_dir to
> >     /home/$USER.
> 
> I see that as orthogonal.  It has the advantage of providing not only
> a sensible default but also a list of endorsed alternatives.
> 
> Whether you *want* to endorse some or all of these alternatives by
> codifying them is a separate question.

I guess I end up doing this anyway.  How complex it becomes is another
question, which I can answer probably only after starting to code it.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Andrey Repin]

Greetings, Corinna Vinschen!

>> > 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%).
>> > 2. If homeDirectory is empty, fall back to /home/$USER.
>> 
>> This is just a subset of what I suggested, so I’m in favor of it.
>> (By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.)

> This would be most easily implemented as well.

> The beauty here is that probably 99% of the home users don't set
> HOMEDRIVE/HOMEPATH in their SAM.

They are always set by default.

> So they get /home/$USER as fallback,

No.

> which is what they got with /etc/passwd as well.  And SAM users have the
> XML-like description field entry as well.

> For AD environments HOMEDRIVE/HOMEPATH are typically set, though.

HOMEDRIVE/HOMEPATH always set.

> Here the users get what they have to use as homedir anyway.

> It's simple, but it should work OOTB for most people.

Yes, it'll work. Just not as you expect it.

>> > 1. Always use /home/$USER and let the admins come up with a matching
>> >   mount point scheme.
>> 
>> That’s neglecting your responsibility as BDFL to set a sensible

> Heh.  I didn't see myself as BDFL yet.  Not sure if that's an honor.

That's a chore. But someone has to pull it.

>> default.  The consequence is that everyone will do it differently, and
>> then you’ll have to support everything on an equal basis, because you
>> chose not to endorse anything.
>> 
>> When you choose a sensible default, you get the option to criticize
>> and even deprecate wild alternative schemes.

> This is a philosophical argument.  You'd have to argue in how far
> always using /home/$USER is NOT a sensible default.

I can give you a whole list of reason, including quotes from Cygwin
documentation, why this is not a good idea.
And "cygwin is not an operating system" will be a red canvas through them.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 14.11.2014, <00:49>

Sorry for my terrible english...

Re: RFC: 1.7.33 problem with user's home directory

[Corinna Vinschen]

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

On Nov 14 01:04, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> > 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%).
> >> > 2. If homeDirectory is empty, fall back to /home/$USER.
> >> 
> >> This is just a subset of what I suggested, so I’m in favor of it.
> >> (By subset I mean that I’d prefer you do essentially the same thing for the non-AD case, too.)
> 
> > This would be most easily implemented as well.
> 
> > The beauty here is that probably 99% of the home users don't set
> > HOMEDRIVE/HOMEPATH in their SAM.
> 
> They are always set by default.

Are you kidding me?  We're talking about creating passwd entries from
user DBs, right?  We're certainly not talking about fetching the
environment variables of the current user to create arbitrary user's
passwd entry.  Ever tried the NetUserGetInfo function?

> > So they get /home/$USER as fallback,
> 
> No.
> 
> > which is what they got with /etc/passwd as well.  And SAM users have the
> > XML-like description field entry as well.
> 
> > For AD environments HOMEDRIVE/HOMEPATH are typically set, though.
> 
> HOMEDRIVE/HOMEPATH always set.

Funny.  I think I skip the rest of your mail.


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 --]

Re: RFC: 1.7.33 problem with user's home directory

[Houder]

>Marco Atzeri wrote:

>>On 11/11/2014 7:40 AM, Andrey Repin wrote:
>>
>>    In short, elusive benefits of having a separate cygwin-specific "clean" homes
>>    versus confusing disjoint of multiple places to look for single user's files,
>>    settings, and other stuff when it comes to backups and migrating profiles.
>>

>This an extremely personal point of view.
>For me, I strongly hate mixing my cygwin home with
>standard windows one.
>I prefer to have separate cygwin home also between 32 and 64 bit
>

>> WBR,
>> Audrey Repin

>Regards
>Marco

Andrey has expressed his opinion on "Cygwin's user home" several times now. And I sincerely
hope that it will not become the accepted view for the location of an user's home.

Please, please, please, do NOT remove the possibility to maintain (the location of an user's
home of) Cygwin as far away from Windows as possible ...

(otherwise I will have another reason the stick to the passwd/group files)

And my apology to Andrey for failing to maintain the "appropriate threading".

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple