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

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 14:19:42 -0500

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 
> <[email-masked]> 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
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 02 Oct 2009 17:42:48 -0400

> rate of 10 objects per-day" or "Jane can create up to 100 FSNs and FSLs

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.

> make garbage collection possible; it'd only make it feasible to check

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.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 16:49:48 -0500

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

> answer to this problem in NFS.

I agree.  What do the authors think?

Nico
--