Thanks for raising it on Ganesha list. Just want to add, once fds are depleted, they are not getting cleaned up even after hours. I needed to restart Ganesha process to recover from this state. I am not sure if idle cleanup code is able to get rid of extra ref and release xprt. I tried with this fix in cleanup code its working for me. https://paste.fedoraproject.org/paste/lapz1NrOlBxS342S4Q79aw Regards, Gaurav On Sun, Dec 2, 2018 at 4:49 AM William Allen Simpson < william.allen.simpson@gmail.com> wrote:
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