Luke Scharf wrote: > Robert Thurlow wrote: > >> Darren.Reed at sun.com wrote: >> >>>>> add service >>>>> set type=nfs >>>>> end >>>> >> >>>> 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. Darren
