Subject: Session channel extension to specify home directory?

From: Joseph Galbraith <[email-masked]>
Date: Wed, 16 Feb 2005 14:42:37 -0700

We just had a user request us to start a shell session
for them in an arbitrary directory.

I was wondering what people would think of the following
extension (for the session channel only):

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "home-directory"
boolean   want reply
string    path to use as home directory [UTF-8]

What do you think?

Are there security implications?  Is it a bad idea?

Would people implement this in their servers?

(It definetly does not go in the connection draft at this late
date-- perhaps it's own document or perhaps another document for 
extensions to the session channel.)

Thanks,

Joseph

---

From: Darren Tucker <[email-masked]>
Date: Thu, 17 Feb 2005 09:29:25 +1100

> for them in an arbitrary directory.
[...]
> Are there security implications?  Is it a bad idea?

Well, for one thing it would let users with restricted shells change 
directories.

What value does it give beyond "(cd /some/path && some command)" ?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 16 Feb 2005 15:45:13 -0700

> Well, for one thing it would let users with restricted shells change 

Argh... and the server has no way of knowing that x is a restricted
shell and disallowing the command does it?

> What value does it give beyond "(cd /some/path && some command)" ?

It works with a NT server.  This might be able to be worked
around by sending cd /some/path\n as artifical user input
before giving control to the user.

But... it works with a VMS server (cd is written
set default disk:[some.path])

But regardless, I don't think it is likely to get many supporters
given the issue with restricted shells.

Thanks,

Joseph

---

From: [email-masked] (Niels Möller)
Date: 17 Feb 2005 12:42:44 +0100

> for them in an arbitrary directory.

Why not just use

  byte      SSH_MSG_CHANNEL_REQUEST
  uint32    recipient channel
  string    "env"
  boolean   want reply
  string    "HOME" 
  string    path to use as home directory

to set the home directory to what you want. You still need to hack
your server to let the provided value override value stored in the
user database, but you don't need any protocol changes.

> string    path to use as home directory [UTF-8]

As for character sets for file names, I would really hope that we can
pass that can of worms over to other protocols, like sftp.

> Would people implement this in their servers?

Probably not.

But it's at least reasonable for a client to have a user interface
that lets the user attempt to set arbitrary environment variables
using SSH_MSG_CHANNEL_REQUEST "env". And reasonable for a server to
have a configurable list of environmant variables that clients are
allowed to change.

Regards,
/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Feb 2005 08:30:35 -0500

> string    path to use as home directory [UTF-8]

starting the session in an arbitrary directory does not to me imply
setting $HOME.

clearly: 

1) reading authorization information (~/.ssh/authorized_keys or 
~/.*hosts) from a client-specified directory is an incredibly bad idea.
I hope nobody's suggesting that but I run into bad ideas like this often
enough that I feel compelled to point it out...

2) setting $HOME after authentication could be accomplished by the env 
request Niels mentioned.

3) setting the working directory to something other than $HOME could be 
accomplished in most shells by sending over a compound command.  if the
account's shell is not a normal shell, you can't do that -- but in that case 
the account is may also be a captive environment, where setting either of 
the working directory or $HOME might violate the assumption of that 
captive environment.

> What do you think?

Needs a few rounds of "what do you really want to do?" with your users.

							- Bill

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 17 Feb 2005 09:13:43 -0700

> enough that I feel compelled to point it out...

Oh, definitely.  "home-directory" might have been the wrong
name... think "initial-working-directory" instead.

> 2) setting $HOME after authentication could be accomplished by the env 

Works under unix, but no place else.

> the working directory or $HOME might violate the assumption of that 

This works in the unix world.

This could be made to work in the NT world for shell, but
perhaps not for exec.

And it doesn't work at all for VMS.

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

I was aiming for a solution that could just work regardless
of the system I was connecting to... but, given the reality
of restricted shells, I think the risk vs. value doesn't
make it worth while to push forward.

Thanks everyone for pointing out the holes in my
hare-brained scheme.

Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Feb 2005 11:57:48 -0500

On Thu, 2005-02-17 at 11:13, Joseph Galbraith wrote:
> but, given the reality of restricted shells, I think the risk vs. value doesn't

ftpd has the same problem with restricted shells; the usual policy IIRC 
is for ftpd to require that the user's shell be listed in /etc/shells.
(restricted shells and the like are typically not listed).

> Thanks everyone for pointing out the holes in my hare-brained scheme.

(wg chair hat off) no, this might be worth pursuing.

							- Bill

---

From: [email-masked] (Niels Möller)
Date: 17 Feb 2005 18:27:51 +0100

Joseph Galbraith <[email-masked]> writes:

> > 2) setting $HOME after authentication could be accomplished by the
> > env request Niels mentioned.
> 

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").

> 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