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