From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Fri 06 Dec 2002 - 16:38:01 GMT
On Wed, 4 Dec 2002 11:06:03 -0500, Nick Craig-Wood wrote
> Alternatively if you have called chrootsafe() then the kernel could
> transmute all chroot() calls into chrootsafe() calls. Once you've
> called chrootsafe() then all bets are off concerning chroot()
> compatibility. This would seem to be a cleaner idea!
No I don't think we can do that. chroot must behave the same way in a vserver.
If application expects weird behavior, they still should work. Newer apps will
learn about chrootsafe and maybe chroot will be forgotten in 10 years :-)
> You might want to change condition 2) to be
>
> chdir(argument)
>
> otherwise this will break applications (for example postfix) - see
> below.
>
> ...
>
> This leads me to explore going down the road chosen by the BSD
> architects :-
>
> Depending on the setting of the `kern.chroot_allow_open_directories'
> sysctl variable, open filedescriptors which reference directories will
> make the chroot() fail as follows:
>
> If `kern.chroot_allow_open_directories' is set to zero, chroot() will
> always fail with EPERM if there are any directories open.
>
> If `kern.chroot_allow_open_directories' is set to one (the default),
> chroot() will fail with EPERM if there are any directories open and the
> process is already subject to a chroot() call.
>
> Any other value for `kern.chroot_allow_open_directories' will bypass the
> check for open directories
>
> So another alternative would be to make a kernel tweakable which
> defaults to 0, say /proc/sys/kernel/safechroot. 0 would mean chroot()
> works exactly like it normally does. 1 would mean :-
I don't like this. If we are not allowed to `fix` chroot and we absolutly need
a safe chroot to 'enter' a vserver, it means we are changing the behavior
of all chroot inside a vserver. So we are breaking some apps.
I would go this way instead
We have chrootsafe and chroot(). chrootsafe is always safe and chroot may be
tweaked system wide (vserver wide in fact) to be equivalent to chrootsafe or not.
After reading your very very long mail, I think we agree here.
So chrootsafe is always safe and chroot, it depends. Both share the same API.
> chroot() fails if
>
> 1) There are opened file handles which are directories
> 2) The current working directory is not the same as the argument
>
> Applications which chroot safely either do
>
> A) chroot("/jail");
> chdir("/");
>
> (as used by postfix)
>
> or
>
> B) chdir("/jail");
> chroot(".");
>
> (as used by djbdns)
>
> or possibly
>
> C) chdir("/jail/cubicle");
> chroot("/jail");
>
> all of which work and currently have the correct effect. Condition 2)
> would break A) and C) which is undesirable.
>
> It might be better to make condition 2)
>
> 2b) chdir(argument)
>
> This would make A) and B) work just fine only breaking the bizarre C)
> which I haven't seen in the wild. C) could be made to work by not
> doing the chdir in 2b) if the cwd is below the argument.
>
> ...
>
> So options presented so far are
>
> i) chrootsafe() syscall with unbreakable root for chroot() calls
> ii) chrootsafe() syscall with chroot() -> chrootsafe() transmutation
> iii) sysctl to control chrootsafe() like behaviour of chroot
>
> Where chrootsafe() is defined as chroot() doing this first :-
>
> 1) Fail if there are opened file handles which are directories
> 2a) Fail if the current working directory is not the same as the argument
> -or-
> 2b) chdir(argument)
>
> My feelings are i) will still require the 000 hack (and hence be
> unacceptable in a similar way) but will provide perfect chroot()
> compatibility. ii) is good and iii) has a precedent from BSD and
> doesn't require another syscall.
>
> 2b) breaks less apps than 2a), but it violates POSIX chroot()
> semantics "chroot does not change the cwd of the process".
>
> --
> Nick Craig-Wood
> ncw1_at_axis.demon.co.uk
>
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc