This was reported on ntirpc at Github.  After DanG's fix for
transport reference counting, Gaurav Gangalwar wrote that s/he
can deplete the available fds with:

   for i in {1..1000}; do echo $i; mount -t nfs -o vers=3,tcp :/export /mnt; umount /mnt; done

There is a configurable parameter limiting the number of
concurrent fds.  They are cleaned up after a fairly long
inactivity timeout.  So an adversary (or runaway client) can
quickly deplete the fds, preventing valid clients from mounting.

The most obvious patch would be for umount to add the same
SVC_DESTROY line that DanG (and previously me) had added for the
TCP well known ports in dispatch.

But that would allow runaway clients to flood the server.
Preventing that seems to be the (undocumented) purpose of the
configurable parameter.

The parameter and cleanup code are relatively old, and added to
ntirpc circa 2013.  Was it a bad idea?

Which security issue is more important?
_______________________________________________
Devel mailing list -- devel@lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org