On Mon, May 05, 2008 at 12:42:49PM -0400, Janne Karhunen wrote: > On Mon, May 5, 2008 at 11:58 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > The statd -n option has actually *never* worked, in any previous version > > of nfs-utils--with it specified, statd can no longer communicate with > > the nfs server on the same host. That means the server won't find out > > when a client reboots. (But I guess even the broken -n may still have > > been sufficient to allow clients to monitor the server and find out when > > the server reboots.) > > -n may work as is in 1.1.* tree: Oh, right, I'd forgotten about that change. > a) It will bind to ANY, so kernel lockd will see packets coming > in from LO. 1.0.x bound the -n interface which will break. > > b) sm-notify is run with -v and correct name (that will bind to > correct IP and use the right name) > > So the only thing missing would be to limit the port visibility > of long-standing sockets; but this should probably be > discussed in another thread if you think it's worth it? Is the only justification just to limit the consequences if a remote exploit is found in statd? If so, iptables seems the better solution, since it provides a uniform way of limiting the exposure of the ports for all the various nfs-related (and other) services, as opposed to just being a one-off thing for statd. --b. -- 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
