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

[Jeffrey Hutzelman <[e-mail]>]

--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.


> 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.