Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03

[Nicolas Williams <[e-mail]>]

On Fri, Oct 02, 2009 at 05:42:48PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, October 02, 2009 02:19:42 PM -0500 Nicolas Williams 
> <[e-mail]> wrote:
> >I agree that orphaning over time is not a security problem.  I was
> >thinking more of the fact that to authorize someone to publish FSNs/FSLs
> >in some NSDB is to authorize them to create unlimited amounts of
> >garbage.  Garbage collection being effectively impossible, the fact that
> >authorization to publish is also authorization to consume all resources
> >seems like a problem to me.  One might want to implement resource
> >controls at NSDBs ("Joe can create FSNs and FSLs in this NSDB, at the
> >rate of 10 objects per-day" or "Jane can create up to 100 FSNs and FSLs
> >in this NSDB").
> 
> I don't know enough about NFSv4's intended model to know if that's actually 
> a problem.  In AFS, the equivalent objects are entries in the volume 
> location database, only administrators get the power to create them, and 
> they are tied fairly tightly to volumes.  The resource you worry about 
> people exhausting is the disk space occupied by volumes, not VLDB entries. 
> What's not clear to me is whether the NFSv4 NSDB's are intended to be 
> similar, or whether the intent is that relatively unprivileged users be 
> able to create arbitrary entries.

The admins for some file server need not be the same as the admins for
some NSDB.  One possible practice is to have an NSDB per-file server in
which to store FSLs, but FSNs really belong in a replicated DB.

I expect that in practice there will be an NSDB per-site/domain and that
NSDB will grant object create writes, in the o=fedfs container, to all
file server admins in that site/domain.

This is a rather minor concern.  I think it merits a mention though.

> >One might also wish to have an optional way to document in an FSN the
> >paths to junctions that are expected to reference the FSNs  Similarly,
> >an optional way to document in an FSL the FSNs that are expected to
> >reference the FSL.  Not that such documentation would be sufficient to
> >make garbage collection possible; it'd only make it feasible to check
> >_intended_ references.
> 
> That does sound like a useful feature.  In practice, intended references 
> are the ones you care about; if you decide a resource is going away, then 
> anyone else who has unexpected references just loses.
> 
> That said, one of the common problems AFS administrators run into is trying 
> to enumerate all of the mount points, other than by doing a find-style 
> traversal of the entire filesystem.  It would be cool to see some sort of 
> answer to this problem in NFS.

I agree.  What do the authors think?

Nico
--