> On Nov 11, 2024, at 5:49 PM, Philip Rowlands <linux-nfs@xxxxxxxxxxx> wrote: > > If a host dies after nsm_make_temp_pathname but before rename(temp, path) we may be left with paths resembling .../server.example.com.new > > Some clever person has registered and installed a wildcard DNS record for *.com.new. > > $ host server.example.com.new > server.example.com.new has address 104.21.68.132 > server.example.com.new has address 172.67.195.202 > > You can see where this is going... > > Our firewall scanners tripped on outbound access to this address, port 111, I assume due to NSM reboot notifications. > > Suggested workarounds include: > * explicitly skip over paths matching the expect tempname pattern in nsm_load_dir() > * use a different tmp suffix than .new, e.g. one which won't work in DNS Indeed, wikipedia provides a non-authoritative listing of top-level domains that includes ".new" as a valid TLD owned by Google: https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains It should be a one-line patch to replace the temp suffix with characters that are not valid in a domain name. > Steps to reproduce: > > # cat /var/lib/nfs/statd/sm/server.example.com.new > 0100007f 000186b5 00000003 00000010 89ae3382e989d91800000000dc00ed000000ffff 1.2.3.4 my-client-name > # sm-notify -d -f -n > sm-notify: Version 2.7.1 starting > sm-notify: Retired record for mon_name server.example.com.new > sm-notify: Added host server.example.com.new to notify list > sm-notify: Initializing NSM state > sm-notify: Failed to open /proc/sys/fs/nfs/nsm_local_state: No such file or directory > sm-notify: Effective UID, GID: 29, 29 > sm-notify: Sending PMAP_GETPORT for 100024, 1, udp > sm-notify: Added host server.example.com.new to notify list > sm-notify: Host server.example.com.new due in 2 seconds > sm-notify: Sending PMAP_GETPORT for 100024, 1, udp > # etc. > > tcpdump shows the outbound traffic: > 22:42:31.940208 IP 192.168.0.131.819 > 172.67.195.202.sunrpc: UDP, length 56 > 22:42:33.942440 IP 192.168.0.131.819 > 172.67.195.202.sunrpc: UDP, length 56 > 22:42:37.946903 IP 192.168.0.131.819 > 172.67.195.202.sunrpc: UDP, length 56 > > The client statd was artificially placed for the purposes of showing the problem, but I hope it's close enough to make sense. > > > Cheers, > Phil > -- Chuck Lever
