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

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Wed, Sep 30, 2009 at 10:31:11PM -0400, Jeffrey Hutzelman wrote:
> --On Wednesday, September 30, 2009 02:36:20 PM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> 
> > - A note that orphaned FSNs and FSLs cannot be easily distinguished
> >   from ones referenced by junctions and FSNs, respectively.  Therefore
> >   objects will tend to pile up.  This is a resource consumption
> >   consideration.  Resource control issues are, IMO, a security
> >   consideration.
> 
> I don't think this is a significant problem, or a security problem at all. 
> The fact that, once I have allocated my resources for an object, you might 
> decide to stop having any references to it, does not create a security 
> problem for me.  This is analogous to my publishing a web page, and then 
> you later deciding not to link to it any more.

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

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.

Nico
--