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

Reply via email to