Luke Scharf wrote:
Robert Thurlow wrote:
[EMAIL PROTECTED] wrote:
Yes, I had a setting like this in mind, as opposed to something that
includes a path to a resource that may be shared.
Are you of the opinion that the global zone shouldn't be able to limit
what the local zone is able to share via NFS, within its root ?
Or that this would/should be done seperately?
My thoughts from here are that a zone can share a slice/LUN/cXtXdXsX,
but not something it accesses via lofs, and if it has such an object,
it gets to make the decision to share. The switch is for the global
zone admin to veto thr ability to share anything.
Why not just run a userland NFS daemon in the zones -- and follow the
existing security model?
That makes all of the security model questions fall away -- and it
also gets fault isolation. There's a slight performance penalty, but
you're running a VM-ish environment anyway.
This thought did occur to me and if you take it to the logical
conclusion, there is no way to restrict which directories or
partitions a zone shares if they are accessible inside the zone.
This presupposes that root in the zone has access to software
to do this...but there have been programs around for over a
decade that are standalone NFS clients, so I can't see why
there isn't an NFS server equivalent.
With respect to performance, there isn't really any serious
performance hit at all for applications running in a local zone.
They interact directly with the kernel and disk, just like they
would if they were running in the global zone.
zones-discuss mailing list