Darren J Moffat wrote On 02/14/07 14:30,: > Menno Lageman wrote: > >> Robert Gordon wrote: >> >>> So could we all agree that: >>> >>> An NFS Server in a zone means that the namespace it exports is >>> restricted >>> to that zone only. By that i mean no global zone access to that >>> namespace, >>> nor would that namespace be re-exported within another NFS Server zone >>> instance ? >> >> I have some trouble parsing that, but my perception of the desired >> behaviour is: >> - a zone can only export resources that are within that zone (i.e. >> everything below it's zonepath), >> - a resource exported from a zone, may not at the same time be >> exported from the global zone; i.e. if zone a exports /export/foo then >> /zones/a/root/export/foo may not be exported by the global zone) >> - zone A and zone B may both export their own /export/foo since those >> are two distinct resources. > > and also that the NFSMAPID_DOMAIN may be different for each zone. > and all security modes are available to all zones, in particular each > zone that is an NFS server maybe in a different Kerberos REALM.
This has been one of my arguements for NFS services in a non-global zone. Besides the separated administrative domains that may be co-located using zones, the other preference that I have is that the services used in the global zone are minimal. I'd rather it be in a separate, non-user (non-service) oriented name service (authentication) domain. Thus any of the authentication and authorization that would need to be done has to be done at the name service level for the zone hosting the service(s). And I can host similar services in different zones for different authentication domains. For all the reasons running a service in a non-global zone is more secure. Steffen
