Re: [PATCH] User chroot

[Jorgen Cederlof <jc@lysator.liu.se>]

hpa@zytor.com ("H. Peter Anvin") writes:

> Followup to:  <20010627014534.B2654@ondska>
> By author:    Jorgen Cederlof <jc@lysator.liu.se>
> In newsgroup: linux.dev.kernel
> > If we only allow user chroots for processes that have never been
> > chrooted before, and if the suid/sgid bits won't have any effect under
> > the new root, it should be perfectly safe to allow any user to chroot.
> 
> Safe, perhaps, but also completely useless: there is no way the user
> can set up a functional environment inside the chroot.

Why? Because he can't create device nodes?

First of all, if /dev is on the same file system as the new root, the
user can ln the device nodes he wants to wherever he wants them in the
new root. He can't change their permissions, but that should not be
necessary.

Since I use devfs, I can't do that. But I decided to try how much I
can do anyway. So I downloaded the big redhat 7.1 image from User-mode
Linux. I unpacked it and extracted it to a directory using User-mode
Linux. Since I was a normal user, I could not create any device nodes
so I left /dev empty.

I chrooted into the directory. Most things seemed to work. I couldn't
use ping, since it needs to be suid root, and ps didn't work for
obvious reasons, but besides that everything looked OK.

I started an Xnest and started a gnome-session in it. Now I ran into
trouble. Some programs complained that they could not open
/dev/null. I touched /dev/null and put a couple of zeroes in /dev/zero
just in case. Now everything worked just fine. Gnome started and I
could run every application included.

The only thing that didn't work was terminal emulators. If I had not
been using devfs, but had /dev on the same file system as /tmp or ~, I
could have linked the needed device nodes. If you want to, you can
have a daemon running outside the root to mirror selected parts of
/proc into new_root/proc.

There are more uses for chroot than running user desktops, as has been
pointed out by others. The same arguments as implementing chroot for
root still applies.

Securing network daemons without needing to be root can be useful. As
an extra bonus, cracked daemons are prevented from gaining root access
from buggy suid binaries.

I'm sure you can think of more uses. Don't assume it has no uses just
because you can't think of anything in two minutes. I tend to use it
quite often now when I am used to it, and I often find it frustrating
to work on computers without this patch.

        Jörgen