Re: Session channel extension to specify home directory?

[nisse%lysator.liu.se@localhost (Niels Möller)]

Joseph Galbraith <galb-list%vandyke.com@localhost> writes:

> > 2) setting $HOME after authentication could be accomplished by the
> > env request Niels mentioned.
> 
> Works under unix, but no place else.

I don't see the problem. Your sshd server on NT is free to special
case "HOME", when it appears in a SSH_MSG_CHANNEL_REQUEST "env", in any
way it likes.

It may be desirable to have some shared view about what setting very
special variables like "HOME" should mean on various systems, but it's
not essential. The effect of setting of *any* environment variable
with SSH_MSG_CHANNEL_REQUEST "env" is inherently implementation
defined.

Keep the protocol simple. If one can implement a new feature in a
reasonable straight forward way with the existing protocol, then don't
invent new request types. And this principle is even more important
for features that are obscure or useful only for a small number of
users. 

(And if you think that the particular name "HOME" is a bad choice, you
can use "CWD" or "SSHD_INITIAL_WORKING_DIRECTORY_FOR_SESSIONS").

> It is pretty easy to come up with a solution that will
> work most places, or require user configuration to get right.

Huh? How are you going to make it work without user configuration? The
*default* behaviour of any reasonable client will still be to *not*
send any home-directory request, and then sessions will be started in
the default home directory for the user, whatever that happens to mean
on the server.

To make use of the feature at all, the user has to learn to say

  --with-cwd /some/place/on/the/drive

when connecting to a system where "/some/place/on/the/drive" makes
sense. I don't think that is going to be significantly easier to
learn, than to say

  --with-env HOME=/some/place/on/the/drive

or

  --with-env CWD=/some/place/on/the/drive

when connecting to systems where the corresponding environment
variable and value make sense.

Regards,
/Niels