Chroot (was Re: Beware of Blindly Un-SHARing a File)

Simon Brown simon at cstvax.UUCP
Sat May 10 04:47:16 AEST 1986


In article <191 at brl-sem.ARPA> ron at brl-sem.UUCP writes:
>> I thought that chroot() caused open()s and creat()s and the like to use the
>> new root, but didn't affect the interpretation of root for exec().  Anybody
>> know for certain?
>> 
>1.  CHROOT is not universal.
>2.  At least 4.2 CHROOT works for any access, I'd think it would be
>    more difficult to go and modify nami to do something different when
>    looking up different types of objects.
>3.  If you chroot, you must have an entire duplicate system under the
>    new root including /etc/passwd, and all commands that might want
>    to get run.


And Version-7 chroot() is the same - ALL filenames are accessed relative to
the new root.

Actually, you don't need very much stuff to be duplicated, unless you're
doing something complicated...

Setting your path to be
	( ../../../bin ../../../usr/bin ../../../usr/ucb etc... )
goes quite a long way to fixing stuff so normal commands executed from
the shell will still work.
Of course /lib and /usr/lib don't exist any more, which is a bit embarrassing
sometimes, like if you want to use the C-compiler, or lint, or something...

Also, the number of "../"'s you need in the path will depend on where
you've chrooted to.

Of course, under 4.2BSD, you can always set up symbolic links to all the
important directories (/dev, /bin, /usr, /etc, /tmp ...) within the
chrooted directory, so everything looks normal, I suppose...


-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----

					Simon Brown

				...!mcvax!ukc!cstvax!simon

						Dept. of computer science
						University of Edinburgh



More information about the Comp.sources.bugs mailing list