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?
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.
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.
I'm talking to others and think that there might be a few other uses of
this kind of 'isolated' filesysetm.
Comments?
thanks,
-FS
note: I'm just trying to figure the rationale behind
this suggestion ...
best,
Herbert
_______________________________________________
Vserver mailing list
[email protected]
http://list.linux-vserver.org/mailman/listinfo/vserver
