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.