Re: [Vserver] A possible new idea

From: Herbert Poetzl <>
Date: Sat 13 May 2006 - 15:25:30 BST
Message-ID: <>

On Fri, May 12, 2006 at 03:17:47PM -0400, Fareha Shafique wrote:
> Herbert Poetzl wrote:
> >On Wed, May 10, 2006 at 05:17:55PM -0400, Fareha Shafique wrote:
> >
> >>Herbert Poetzl wrote:
> >>
> >>>On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote:
> >>>
> >>>>After asking various questions about unification, I don't think
> >>>>vhashify quite supports what I have in mind. I wanted to get some
> >>>>opinions/ideas from the users of this mailing list.
> >>>>
> >>>>I am thinking if vservers can somehow be used to provide MAC
> >>>>(Mandatory Access Control) through containers. For example, a
> >>>>vserver shares the same filesystem as the host server, with read
> >>>>and write access to the host files being defined through a set
> >>>>of MAC policies. In this way, different policies can be defined
> >>>>for different vservers. Also, writes can be contained within
> >>>>a vserver (so that if a file is written to, a copy is made in
> >>>>the vserver's space) and integrated with the host only through
> >>>>explicit 'commits' to allow, for example, new configurations to be
> >>>>tested in an environment exactly the same as the host server and
> >>>>then transferred to the host using a commit.
> >>>>
> >>>>Any comments please?
> >>>>
> >>>sounds interesting, any ideas how to realize this?
> >>>
> >>Well, my first impression of vservers was that it provided a kind
> >>of containment that I have mentioned. I mean after quickly going
> >>over the short introduction, I thought that a vserver has read
> >>only access to the host server's files and CoW is used whenever
> >>the vserver modifes a file. However, after installing a vserver, I
> >>realized this was not the case. And after asking a few questions
> >>on the mailing list, I learnt that there is no direct way to do
> >>this. I was hoping to find out what some of those involved in the
> >>development of linux-vserver thought about the feasibility of this
> >>idea.
> >
> >well, yes, they did :)
> >
> So they thought about it, but found it infeasible? or unecessary?

the thing is, there are a bunch of arguments against
this setup, namely:

 - the host system usually is a minimal setup tailored
   to administration and management of the guests
   including security stuff and backup/failover

 - you do not change the host system very often, you
   want to keep it updated in regard to security though

 - for security reasons, you do not 'share' the host
   system with any guest you give avay ...

 - disk space is very cheap, so doing a similar approach
   with a 'guest template', which is shared or unified
   with many guests is not a big deal

 - different distros require different userspace, the
   amount of shared files is minimal across distros

 - CoW works fine, but reombining with a 'read-only'
   base which can be changed is a hard task, and usually
   not worth the efford ...

> >>So basically, at the moment, I don't really have much idea how to
> >>realize this, but I am hoping those more involved with vserver will
> >>some ideas to share :)
> >
> >aha, good, well, what would be the advantage over the
> >currently established way to do this, i.e. have a
> >template (some cleaned up version of your host system)
> >and update guests either individually or at-once with
> >the v* tools (like vrpm, vapt, vyum ...)?
> >
> >why would somebody want to _share_ the host files with
> >the guest, instead of having a separate filesystem for
> >them?
> >
> >
> It will
> 1) save space: Esp. in the example I gave of using vservers to provide
> MAC. So if we want to provide different permissions for different
> users/applications, the permissions can be defined per vserver. Rather
> than each vserver having a copy of the host filesystem, the guest and
> host can share filesystems...I'm thinking this method will make access
> policies easier to write than those of SELinux.

how much will it save, 400MB or maybe 1GB?
I don't think this is really an issue, except on
embedded systems

> 2) make upgrades more manageable. For example, rather than having a test
> vserver to test upgrades and have a separate production vserver to which
> all tested upgrades have to be moved and configuration re-done, sharing
> a filesystem will allow a 'commit-like' functionality to automatically
> handle passing an upgrade from the vserver to the host.

that is something which might be interesting, but
I think no current filesystem/overlay/cow feature
can handle 'commits' yet

> I'm talking to others and think that there might be a few other uses
> of this kind of 'isolated' filesysetm.
> Comments?

keep thinking about it, usually the best ideas start
with 'impossible' or 'useless' :)


> thanks,
> -FS
> >note: I'm just trying to figure the rationale behind
> >this suggestion ...
> >
> >best,
> >Herbert
> >
> >
> >
Vserver mailing list
Received on Sat May 13 15:25:57 2006

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sat 13 May 2006 - 15:26:04 BST by hypermail 2.1.8