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
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Fri May 12 20:18:25 2006