On Thu, Feb 15, 2007 at 01:30:44PM -0800, [EMAIL PROTECTED] wrote: > Luke Scharf wrote: > >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.
Not entirely. Look at OpenAFS, which does just that. There are two issues: 1) You need an open-by-FID (fsid+inode) type of system call, which gets us back to the issue that no single filesystem should have separate sub-directories shared by different zones. 2) You need a bunch of system calls like open(2) but augmented with an argument specifying who to do the operation as. I blogged about (2) here: http://blogs.sun.com/nico/entry/building_filesystem_servers_in_user in the context of "hostafs" -- a user-land AFS server for serving non-AFS local filesystems. Normally OpenAFS gets around (1) and (2) by implementing the filesystem in user-land, not just the protocol. This means that there's no local access to AFS-shared filesystems. (Hmmm, much of ZFS runs in user-land, so perhaps one could run an all-user-land NFS+ZFS server, but, does anyone really want to build such a thing?) Of course, you still need an implementation of NFS in user-land... > 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. Well, this is true, but if you restrict access via an open-by-FID syscall (see (1) above) to filesystems owned only by the zone whence the call is made, then this problem goes away. In practice you can't have NFSv3 (or AFS) service without open-by-FID. For NFSv4 you can get by without it with some minor limitations. > 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. See above. > 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. But we're talking about an NFS server in user-land -- surely there'd be a perf hit as compared to NFS service in kernel-land (if nothing else it may complicate server-side zero-copy, but then, you can't have that if you want crypto in the protocol, not without RDDP, IPsec-capable RNICs and channel binding to IPsec, but that's all a long story). Nico -- _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
