From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 04 Dec 2002 - 00:29:51 GMT
On Tue, Dec 03, 2002 at 05:56:01PM -0500, Jacques Gelinas wrote:
> What about a new syscall working like chroot but with the following extra
>
> The syscall fails if
>
> -There are opened file handles which are directories
> -The current working directory is not the same as the argument
>
> Or we can drop the second requierement and use the current working directory
> as the new root, so the system call would be parameter-less and even simpler
> since we will simply copy one pointer over an other, no parameter validation at
> all.
>
> We need a good name for the system call. chrootsafe() ?
>
> The system call would have another effect. It will record the new root
> in two places in the process. One is the current root of the process and the
> other is the unbreakable root. The idea is that chroot may still be used
> inside a chrootsafe() world and the weakness in chroot() may be used to
> break chrootsafe() as well. So this unbreakable root would be used as a test
> where the horrid 000 test is currently done.
>
> In fact, the unbreakable root could be the parent of the new root.
>
> This seems very easy to implement and would please everyone. It also
> enable vservers inside vserver. the current chmod 000 works both ways
> and prevent a vserver to enter the vservers it would have created.
>
> So any comment on chrootsafe(). Looks very easy
sounds reasonable, I would like to add some thoughts regarding
(not only) the quota issues (for and within virtual servers) ...
(just some thoughts I would like to see discussed)
(just for information) currently missing (quota) features:
- available diskspace (df) on shared partition
does not reflect context quota limitations
- per vserver user/group quota is not 100% because
of the missing/unavailable quota files (although
quota accounting and limitation works perfect ;)
maybe we should think about some kind of virtual, directory
based filesystem, which gets somehow "magically" defined
at context creation ...
this would at least solve the following issues:
- special cage (root jail) requirement
- per context filesystem limitation
- on the fly resizing of vserver root partitions
- per context user/group quota support
(by faking the required quota files)
and could propably bring a new dimension by:
- making unification totally transparent
(the idea would be to provide a layer, which
does a total unification until a file is
changed, in that case, a copy will jump in,
very much like the copy on write mmap)
- separating permissions/quota/context info
from the actually used filesystem
- advanced backup/failover capabilities
best,
Herbert
> ---------------------------------------------------------
> 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