Hi all, J. Bruce Fields wrote: >> Changing /proc/sys/sunrpc/max_resvport to 1023 again resolves this >> issue, however defeats the purpose for the initial problem. I still need >> to look into the code for hte portmapper, but is it easily possible that >> the portmapper would accept nfsd requests from "insecure" ports also? >> Since e are (mostly) in a controlled environment that should not pose a >> problem. >> >> Anyone with an idea? > > The immediate problem seems like a kernel bug to me--it seems to me that > the calls to local daemons should be ignoring {min_,max}_resvport. (Or > is there some way the daemons can still know that those calls come from > the local kernel?) I just found this in the Makefile for the portmapper: # To disable tcp-wrapper style access control, comment out the following # macro definitions. Access control can also be turned off by providing # no access control tables. The local system, since it runs the portmap # daemon, is always treated as an authorized host. HOSTS_ACCESS= -DHOSTS_ACCESS #WRAP_LIB = $(WRAP_DIR)/libwrap.a WRAP_LIB = -lwrap # Comment out if your RPC library does not allocate privileged ports for # requests from processes with root privilege, or the new portmap will # always reject requests to register/unregister services on privileged # ports. You can find out by running "rpcinfo -p"; if all mountd and NIS # daemons use a port >= 1024 you should probably disable the next line. CHECK_PORT = -DCHECK_PORT I'll try to head down the road of not checking for the ports anymore - on exposed ports I could block the listening daemons from the outside world by iptables. Not nice, but probably a solution (and yet another custom package for us). Anyone who knows a good reason not to walk this route? Cheers Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html