Messages in this thread |  | | Date | Sun, 17 Nov 1996 09:56:49 +0200 (EET) | From | Linus Torvalds <> | Subject | Re: Glitch in sys_chroot() |
| |
On Fri, 15 Nov 1996, Alan Cox wrote: > > Changing chroot, and being able to discard all existing directory handles > is part of being able to build a secure subenvironment for users to play in.
But security is only _one_ issue with "chroot()".
There are actually other uses for chroot(), like just creating a temporary environment that gives another view of the system. It doesn't have to be security-oriented per se, it can be used more to just have two independent environments for working.
In some cases you'd _want_ to be able to move between environments. Focusing on only security is silly: the whole basic design of UNIX is to allow the user to do what he wants, not to make it harder to do "strange" things.
For example, when Linux/alpha got ELF libraries, the first test- environment was done under chroot. Not due to security at all, but in order to install a new set of binaries without having to throw the old (stable) set away. For that kind of chroot() use it would have been positively detrimental to make chroot() do anything more than it does now.
Just as an example, with the current chroot() behaviour we can do stuff like this:
- install a new test-gcc in a chroot environment - compile programs _outside_ the chroot-environment with
change_root /gcc /usr/bin/gcc file.c -o file.o
and magically it all works correctly: the compiler (and all header files: /usr/include etc) come from the chroot'ed environment, while the "file.c" and "file.o" files are from _outside_ the chroot() environment exactly because we do not change the current working directory.
In short, if you look at chroot() as only a security feature, you're missing a lot of the implications of chroot(). I'm not so stupid that I'd limit a very useful system call only because there are stupid programs out there that can't do a "chdir()" at the same time as chroot.
So until somebody comes up with a GOOD argument for doing chdir() automatically, this discussion is ended. Please think of ALL the implications, and don't concentrate on just one small part of the system (security).
As I said, security isn't trivial, and anybody who thinks he can get rid of security holes by trivial fixes is very naive indeed. Sure, you can make any system secure by disabling useful features, but that's just plain stupid.
Just to show exactly HOW stupid this whole discussion is, here's inane argument #1: "The suid/sgid bits are the main source of security holes, so why don't we disable those altogether, and then we'll have a secure system".
I'm not that stupid,
Linus
|  |