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

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Sep 2009 22:31:11 -0400

--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've lacked the time to pay any more than fleeting attention to the NFSv4 
work, but not surprisingly, the concepts mentioned here have analogues in 
AFS.  What NFS calls a "fileset" we call a "volume".  Volumes have names, 
and each AFS "cell" (collection of servers and volumes under common 
administrative control) has a database which maps volume names to 
locations.  What NFS calls a "junction" we call a "mount point", which is a 
special object in the filesystem which refers to another volume, possibly 
in another cell.

My observation over the years has been while it is possible to create mount 
points anywhere in the filesystem, referring to any volume in any cell, it 
is relatively uncommon to do so.  Most sites apply some structure to their 
filesystem namespace, such that a volume used for a particular purpose will 
have a fairly predictable name, and be referred to by a "canonical" mount 
point in a fairly predictable location.  Volume and mount point are 
typically created at the same time by the same administrator (or, more 
likely, by a set of tools designed to automate this process), and are also 
removed at the same time when no longer needed.  Others may create 
additional mount points, but this is fairly uncommon and most sites make 
few or no provision for keeping track of them.

In AFS, cross-cell mount points are even less common; the most common usage 
involves a single mount point to a canonical volume in each foreign cell 
(by convention, named "root.cell"), with other cross-cell mount points 
being extremely rare in most deployments.  I suspect actual deployment of 
NFSv4 will be somewhat different in this respect, but one aspect I would 
expect to remain similar is that the looser the organizational relationship 
between the location of a junction and that of its target, the more likely 
the target will be one of a small number of well-publicized entry points.

The upshot is that this model is unlikely to create the sort of problems 
you imagine, because in practice there will always be at least one 
"canonical" junction leading (eventually) to any given fileset.  Note that 
this point also extends to the intermediate objects, but more so; I'd 
expect management of FSN's and FSL's in practice to be fairly closely tied 
to management of the filesets themselves.

-- Jeff