Re: [PATCH review 6/6] vfs: Cache the results of path_connected

["J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>]

On Mon, Aug 31, 2015 at 04:17:28PM -0500, Eric W. Biederman wrote:
> "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> writes:
> 
> > On Fri, Aug 28, 2015 at 03:43:02PM -0400, J. Bruce Fields wrote:
> >> On Wed, Aug 05, 2015 at 11:28:55AM -0500, Eric W. Biederman wrote:
> >> > The file handle reconstitution code can certainly be affected by all of
> >> > this.  Given that it is an failure if reconnect_path can't reconnect the
> >> > path of a file handle.  I think it can reasonably considered an error in
> >> > all cases if that path is outside of an exported bind mount, but I don't
> >> > know that area particularly well.  The solution might just be don't
> >> > export file handles from bind mounts.
> >> 
> >> I don't think there's any new cause for concern here.
> >> 
> >> I'd quibble with the language "don't export filehandles", *if* by that
> >> you mean "don't tell allow anyone to know filehandles".  They're
> >> guessable, so keeping them secret doesn't guarantee much security.
> >> 
> >> The dangerous operation is open_by_handle, and people need to understand
> >> that if you allow someone to call that then you're effectively giving
> >> access to the whole filesystem.  That's always been true.  (We don't
> >> really have an efficient way to determine if a non-directory is in a
> >> given subtree anyway.)
> >>
> >>
> >> Such filehandle-guessing attacks on NFS have long been well-understood.
> >> NOSUBTREECHECK can prevent them but causes other problems, so isn't the
> >> default.
> 
> Interesting.  I guess it makes sense that filehandles can be guessed.  I
> wonder if a crypto variant that is resistant to plain text attacks would
> be a practical defense.

People have considered it.  I don't think it would be hard: just
generate some permanent server secret and use it to encrypt all
filehandles (and decrypt them again when looking them up).

Some of the reasons I don't think it's been done:

	- Well, it's work, and nobody's really felt that strongly about
	  it.

	- It's usually not that hard to create another filesystem when
	  you need a real security boundary.

	- Filehandles are forever.  But it's hard to keep secrets
	  forever, especially when they have to be transmitted over the
	  network a lot.  (In more detail: client applications can hold
	  long-lived references to filesystem objects through open file
	  descriptors or current working directories.  They expect those
	  to keep working even over server reboots.  We don't even know
	  about those references.  So any filehandle we give out could
	  be looked up at any time in the future.  The only case where
	  we consider it acceptable to return ESTALE is when the
	  object's actually gone.)

> We do have d_ancestor/is_subdir that is a compartively efficient way to
> see if a dentry is in a given subtree.  As it does not need to perform
> the permission checks I believe it would be some cheaper than the
> current nfs subtree check code.  I don't know if that would avoid the
> known problem with the subtree check code.  Nor do I know if it would be
> cheap enough to use for every nfsd operation when a file handle is
> received.

That would solve the problem for directories, but not for files.  For
non-directories we'd need special support from the filesystem (since at
the time we look up the filehandle the parent(s) may not be in the
dcache yet).  Steps to check subtree membership would be roughly (number
of hardlinks) * (average depth).  I think it's probably not worth it.

Anyway, forgive the digressions....

--b.