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
[email protected]
http://list.linux-vserver.org/mailman/listinfo/vserver
