From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Thu 04 Nov 2004 - 01:32:22 GMT
sam_at_vilain.net (Sam Vilain) writes:
> >>> (a2) operating from the outside in the vserver
> >>ACK; (a2) is the real problem and required by tools like vrpm or
> I think this simply isn't always going to be possible in the general
> case. For instance, in my case, my /usr, /bin, /sbin, /lib are bind
> mounts from the shared OS partition into the per-vserver partition.
Not really a problem for 'rpm'... just add these directories to
> So, because we broke the `sanity condition' that all you need to do to
> enter a vserver is is chroot + ~chcontext() with namespaces, you can't
> expect to be able to use commands like `rpm --root /vservers/foo',
The (external) 'vrpm' utility does a little bit more than 'rpm --root':
1. it enters the context's namespace
2. it creates a new namespace
3. it maps the rpm-database which is stored outside of the vserver into
the vserver with a 'mount --bind'; same applies to rpm configuration
4. it executes the 'rpm --root' through an LD_PRELOAD wrapper which
modifies e.g. the execv() function. So, rpm scriptlets will be
executed in the vserver context
> Would it solve anything by considering namespaces as wholly a property
> of the security context?
The initial namespace is stored as a context-property (with the
vc_set_namespace() syscall) and this is done by the scripts already.
A related syscall is vc_enter_namespace(xid_t) which replaces the
namespace of the calling process with this of the context.
> However, unlike the IP chroot, these namespaces are dangerous things.
> If you have one lying around that you can't see,
This can not happen: a namespace is always bound to a process (and
perhaps a context, but I am not sure about this). When the last process
dies, the namespace disappears automatically. So hanging namespaces
should be no issue -- at least theoretically...
In reality, some 2.6 kernel introduced a delayed process-removal so that
contexts (and namespaces) stay alive although all processes exited. An
ugly workaround is 'mount -o remount,rw /proc' but this is really ugly.
> 4. do all required/listed mounts that *don't* need outside VFS access,
> ie `fstab.local'
FWIW, the difference of the current 'fstab.local' and 'fstab' file is
that 'fstab' will be mounted in a 'chbind' environment and 'fstab.local'
in the host-ip environment. Reasons for this (stalled NFS mounts) seem to
be solved in better ways in recent kernels already, so it will disappear
probably in near future.
> Entering from the outside would be like:
> 1. call vserver function to enter context. This also moves you into
> the correct namespace, but until you chroot(), you still have
> outside VFS access by means of your processes' `/' and/or cwd.
This is exactly the current way...
Vserver mailing list