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:
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.
> 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).
zones-discuss mailing list