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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:15 EST