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

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
> >>vapt-get.
> 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
   and apt-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

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 Thu 04 Nov 2004 - 11:08:32 GMT by hypermail 2.1.3