Herbert Poetzl wrote:
>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 ...
>
>
I'm not quite sure I understand what you mean by 'give away'. Can you
please explain this more?
> - 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' :)
>
>best,
>Herbert
>
>
>
>>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 Mon May 15 19:43:57 2006