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' :) 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