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 <[EMAIL PROTECTED]> > vserver: run general purpose virtual servers on one box, full speed! > http://www.solucorp.qc.ca/miscprj/s_context.hc
