openssh unix dev - Mar 2002 - [Bug 177] chroot tools for OpenSSH 3.1p1

http://bugzilla.mindrot.org/show_bug.cgi?id=177





------- Additional Comments From markus at openbsd.org  2002-03-22 08:07 -------
chroot would be nice to have, but having sshd chroot for /./ in $HOME
is not a standard behaviour.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=177





------- Additional Comments From nkadel at bellatlantic.net  2002-03-22 08:43
-------
Well, it wasn't my original idea, I'm just trying to get it implemented 
cleanly. It's not "common behavior" for rather different chroot
environments,
such as the limited environment of ftpd. That works for anonymous ftpd logins 
because the ftpd remains present as the user's interactive shell,
interpreting
their commands. To do this for OpenSSH, sshd or something like it would have to 
be use some kind of restricted shell, maintained and forked off, and it would 
prohibit local user login.

By using the "/./" as a flag for the local user, the chroot behavior
remains
under root control, the user can use any shell the admin is willing to install 
for them, and once can even created shared environments as follows.

    nkadel:*:1000:1000:Shared SSH chroot for 
Nico:/home/shared/./../nkadel:/bin/bash

If I log in locally, or look for my email, I wind up in /home/nkadel. If I come 
in via SSH, I wind up in /home/shared.

This as opposed to:

    nkadel2:*:1000:1000:chroot SSH for Nico:/home/nkadel/./:/bin/bash

For this, I'd wind up in /home/nkadel in a chroot cage.

Does this make sense? I'd welcome better ideas.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.