From: edward_at_paradigm4.com.au
Date: Wed Feb 06 2002 - 22:21:53 EST
On Wednesday, 6 February 2002 at 13:30, Jacques Gelinas wrote:
> You have a clean state. No open directory. You current
> directory point to /vservers/v1
>
> You do chroot ("/vservers/v1");
>
> At this point, all is clean.
>
> Then root inside the vserver v1 do this
>
> int fd = open ("/",O_RDONLY);
>
> Now fd point to /vservers/v1 effectivly
>
> chroot ("/tmp");
>
> Now we are in a chroot inside a chroot. Note that on the kernel
> side, the current process has its root in /vservers/v1/tmp, but
> there is no such a thing as nested chroot. I mean, all the kernel
> knows from now on is that this process has /vservers/v1/tmp
> as its root and it can't tell the difference between a process
> like this one and another process having done
>
> chroot ("/vservers/v1/tmp")
>
> right from the root server.
>
> Now, the process simply do
>
> fchdir (fd)
>
> Its current directory is now /vservers/v1. So even if the chroot
> system call had force the current directory to /tmp (/vservers/v1/tmp)
> now, the process current directory is behind the process root. From
> now on, the process can perform file operation behind its root.
> But it is locked into using relative addressing. Whenever it does
Yep, I understand now. That sucks. What's the point of chroot then if it's so easy to break out (
provided you have CAP_SYS_CHROOT of course ).
I have to admit I was somewhat reluctant to apply vfs_permission change to the 2.2.20ctx patch
because I was fearing that it may break some progs and I didn't understand the issue fully.
Now that I do, I'll have to add the fix asap.
thanks
Ed
This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT