Edward Pilatowicz wrote:
On Thu, Feb 15, 2007 at 12:28:40AM +0000, Darren J Moffat wrote:
Nicolas Williams wrote:
On Wed, Feb 14, 2007 at 03:27:30PM -0600, Robert Gordon wrote:
There maybe a conflicting security requirement here. Lets say
I'm SA of the zone and i have exported /export/foo with krb5i
(since my foo really needs tight security :) ) to a limited
set of clients. Then along comes Mr Global SA and exports it
with auth_sys to any old nfs client..
seems like that might be an issue ?
Clearly if a zone is in charge of its exports then there should be no
trivial way for a g-z admin to interfere short of using zlogin to
interfere from within that zone.
The interesting question is: how this works on upgrade where the g-z had
shares inside a zone. Do we move these shares into the zone, or do we
have a concept of zones that delegate sharing power to the g-z?
delegation just like stack instances and ZFS.
except lofs doesn't work like zfs or stack instances.
What does lofs have to do with sharing over NFS ?
with lofs the global zone SA can share any global zone file or
directory with as many zones as he wants to.
I read the statement as the g-z admin sharing with AUTH_SYS when the
local zone admin shared with one of the kerberos mechs.
share was implying NFS I thought not share between local zones on the
same system with lofs.
> if the local zone SA
has sensitive data that they don't want other zones to have access
to they shouldn't put it into a shared location. and in the end any
zone SA must trust their global zone SA. (since the global zone SA
could always just cd into any zone on the system, tar up whatever they
want, and distribute it to whoever they want.)
You must always trust your global zone SA to some extent.
If this really is about different sensitivity levels of data in each
zone then using Trusted Extensions sounds like it might be the correct
approach - this is exactly what it was designed for.
--
Darren J Moffat
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
