About this list Date view Thread view Subject view Author view Attachment view

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


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 13 Dec 2002 - 03:49:14 GMT by hypermail 2.1.3