Kyle Moffett napsal(a):
> On Sep 26, 2007, at 06:27:38, David Newall wrote:
>> Kyle Moffett wrote:
>>> David, please do tell myself and Adrian how "locking down" chroot() 
>>> the way you want will avoid letting root break out through any of 
>>> the above ways?
>>
>> As has been said, there are thousands of ways to break out of a 
>> chroot.  It's just that one of them should not be that chroot lets 
>> you walk out.  I can't explain it clearer than that.  If you don't 
>> see it now you probably never will.
>
> Let me put it this way:  You *CANNOT* enforce chroot() the way you 
> want to without a completely unacceptable performance penalty.  Let's 
> start with the simplest example of:
>
> fd = open("/", O_DIRECTORY);
> chroot("/foo");
> fchdir(fd);
> chroot(".");
>
> If you had ever actually looked at the Linux VFS, it is completely 
> *impossible* to tell whether "fd" at the time of the chroot is inside 
> or outside of "/foo" without tracking an enormous amount of extra state.
so there *is* solution. It is possible. I solved it. I have patch and it 
is working. So if you find some way how to break it I woud glad if you 
tell me it.
> Even then, any such determination may not be valid since an FD may be 
> opened to an inode which is hardlinked at multiple locations in the 
> directory tree.  It could also be bind-mounted at multiple locations, 
> or it may not even be mounted at all in this namespace (CDROM that was 
> lazy-unmounted).  That FD may be later passed over an open UNIX-domain 
> socket from another process.  Moreover, arbitrarily closing FDs would 
> break a huge number of programs.  Furthermore, since you can't fix the 
> "trivial" case of 'fchdir()', then there's no point in even 
> *attempting* to fix the "cwd is outside of chroot" problem, although 
> that is basically equivalent in difficulty to fixing the "dir-fd is 
> outside of chroot" problem.
>
> As for the nested-chroot() bit, the root user inside of a chroot is 
> always allowed to chroot().  This is necessary for test-suites for 
> various distro installers, chroot once to enter the installer playpen, 
> installer chroots again to configure the test-installed-system.  Once 
> you allow a second chroot, you're back at the "can't reliably and 
> efficiently track directory sub-tree members" problem.
>
> So if you think it can and should be fixed, then PROVIDE THE CODE.
Miloslav Semler