[lkml]   [2001]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] User chroot
H. Peter Anvin writes:
> [somebody]

>> Have you ever wondered why normal users are not allowed to chroot?
>> I have. The reasons I can figure out are:
>> * Changing root makes it trivial to trick suid/sgid binaries to do
>> nasty things.
>> * If root calls chroot and changes uid, he expects that the process
>> can not escape to the old root by calling chroot again.
>> 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. In other
> words, it's all pain, no gain.

Normal users can use an environment provided for them.

While trying to figure out why the "heyu" program would not
work on a Red Hat box, I did just this. As root I set up all
the device files needed, along Debian libraries and the heyu
executable itself. It was annoying that I couldn't try out
my chroot environment as a regular user.

Creating the device files isn't a big deal. It wouldn't be
hard to write a setuid app to make the few needed devices.
If we had per-user limits, "mount --bind /dev/zero /foo/zero"
could be allowed. One way or another, devices can be provided.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.144 / U:0.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site