summaryrefslogtreecommitdiffstats
path: root/utils/statd/rmtcall.c
Commit message (Collapse)AuthorAgeFilesLines
* rpc.statd: Bind downcall socket to loopback addressChuck Lever2011-08-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the past, rpc.statd posted SM_NOTIFY requests using the same socket it used for sending downcalls to the kernel. To receive replies from remote hosts, the socket was bound to INADDR_ANY. With commit f113db52 "Remove notify functionality from statd in favour of sm-notify" (Mar 20, 2007), the downcall socket is no longer used for sending requests to remote hosts. However, the downcall socket is still bound to INADDR_ANY. Thus a remote host can inject data on this socket since it is an unconnected UDP socket listening for RPC replies. Thanks to f113db52, the port number of this socket is no longer controlled by a command line option, making it difficult to firewall. We have demonstrated that data injection on this socket can result in a DoS by causing rpc.statd to consume CPU and log bandwidth, but so far we have not found a breach. To prevent unwanted data injection, bind this socket to the loopback address. BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=177 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* statd: Remove NL_ADDR() macroChuck Lever2010-01-151-13/+13
| | | | | | | | | | | | Clean up: The contents of NL_ADDR are fixed: they are always the IPv4 loopback address. Some time ago, the use of NL_ADDR() was stubbed out of the NLM downcall forward path, replaced with a constant IPv4 loopback address. Stub it out of the reply path as well, and then remove NL_ADDR entirely. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* statd: Update rmtcall.cChuck Lever2010-01-151-136/+45
| | | | | | | | | | | Replace the open code to construct NLM downcalls and PMAP_GETPORT RPC requests with calls to our new library routines. This clean up removes redundant code in rmtcall.c, and enables the possibility of making NLM downcalls via IPv6 transports. We won't support that for a long while, however. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* statd: Replace note() with xlog() in rpc.statdChuck Lever2009-11-241-19/+17
| | | | | | | | | | | To facilitate code sharing between statd and sm-notify (and with other components of nfs-utils), replace sm-notify's nsm_log() with xlog(). Since opt_quiet is used in only a handful of insignificant cases, it is removed. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* rpc.statd: Stop overloading sockfd in utils/statd/rmtcall.cChuck Lever2008-09-261-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linux kernel's lockd requires that rpc.statd perform notification callbacks from a privileged source port. To guarantee rpc.statd gets a privileged source port but runs unprivileged, it calls statd_get_socket() then drops root privileges before starting it's svc request processing loop. Statd's svc request loop is the only caller of the process_foo() functions in utils/statd/rmtcall.c, but one of them, process_notify_list() attempts to invoke statd_get_socket() again. In today's code, this is unneeded because statd_get_socket() is always invoked before my_svc_run(). However, if it ever succeeded, it would get an unprivileged source port anyway, causing the kernel to reject all subsequent requests from statd. Thus the process_notify_list() function should not ever call statd_get_socket() because root privileges have been dropped by this point, and statd_get_socket() wouldn't get a privileged source port, causing the kernel to reject all subsequent SM_NOTIFY requests. So all of the process_foo functions in utils/statd/rmtcall.c should use the global sockfd instead of a local copy, as it already has a privileged source port. I've seen some unexplained behavior where statd starts making calls to the kernel via an unprivileged port. This could be one way that might occur. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* rpc.statd: Use __func__ in dprintfChuck Lever2008-09-261-23/+27
| | | | | | | | | | | | Clean up: The named function in many of the debugging messages in utils/statd/rmtcall.c is out of date. To prevent this from happening in the future, replace these with __func__. Also, note() and dprintf() do not require a terminating '\n' in their format string. So make all invocations consistent. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Steve Dickson <steved@redhat.com>
* Be more cautious about use for privilege ports (<1024).Neil Brown2007-04-161-11/+23
| | | | | | | | | | | | | Ports < 1024 are a scarce resource and should not be used carelessly. Technically they should be not used at all without registration with IANA, but sometimes we need them despite that. So: for the socket that RPC services listen on, don't use a <1024 port by default. There is no need. For sockets that we send messages on, that are long-lived, and that might need to appear 'privileged', avoid using a number that is registered in /etc/services if possible.
* statd - remove try_to_resolveNeil Brown2007-03-201-60/+2
| | | | | | try_to_resolve is used to resolve a hostname when sending a notification. But we now only send notifications to localhost, so name resolution is not needed.
* Remove notify functionality from statd in favour of sm-notifyNeil Brown2007-03-201-132/+19
| | | | | statd now execs sm-notify to notify peers and only listens to monitor requests and remote notifications itself.
* Detect if glibc provides socklen_t and use that insteadGreg Banks2006-06-271-1/+5
| | | | | of int in those cases which generate compile warnings, e.g. the last argument of recvfrom().
* Define and use HIAVE_IFADDRS_HNeil Brown2006-04-171-1/+7
|
* Autogen updateneilbrown2005-12-201-1/+3
|
* Assorted changes from Steve Dicksonneilbrown2005-10-061-2/+58
|
* Make statd_get_socket actually honour the 'port' parameter.neilbrown2005-02-281-2/+9
|
* statd fixesneilbrown2004-12-061-0/+10
|
* Support --ha-callout for high-availability calloutsneilbrown2004-09-061-0/+3
|
* Rename statd log() to note() to avoid conflict with ISO C.chip2003-08-221-23/+23
|
* 2001-03-21 H.J. Lu <hjl@lucon.org>hjl2001-03-211-3/+4
| | | | | | | | | | | | | | | | | | | | | | * nfs-utils.spec: Regenerated. (Release): Set to 3. 2001-03-21 Ion Badulescu <ionut@cs.columbia.edu> * utils/statd/statd.c (main): make sure file descriptors 0-2 are open to /dev/null. 2001-03-21 H.J. Lu <hjl@lucon.org> * support/nfs/rpcmisc.c: Restore the change made on 2001-03-10. * support/nfs/rpcmisc.c: Likewise. * utils/rquotad/rquota_svc.c: Likewise. * utils/rquotad/rquotad.man: Likewise. * utils/statd/Makefile: Likewise. * utils/statd/rmtcall.c: Likewise. * utils/statd/simulate.c: Likewise. * utils/statd/statd.c: Likewise. * utils/statd/statd.man: Likewise.
* 2001-03-11 H.J. Lu <hjl@lucon.org>hjl2001-03-121-4/+3
| | | | | | | | | | | | * support/include/rpcmisc.h: Undo the change made on 2001-03-10. * support/nfs/rpcmisc.c: Likewise. * utils/rquotad/rquota_svc.c: Likewise. * utils/rquotad/rquotad.man: Likewise. * utils/statd/Makefile: Likewise. * utils/statd/rmtcall.c: Likewise. * utils/statd/simulate.c: Likewise. * utils/statd/statd.c: Likewise. * utils/statd/statd.man: Likewise.
* 2001-03-10 Tavis Barr <tavis@boole.isetr.columbia.edu>hjl2001-03-111-3/+4
| | | | | | | | | | | | | | | | | * utils/rquotad/rquotad.man: Updated for -p. * utils/statd/statd.man: Likewise. 2001-03-10 Ion Badulescu <ionut@cs.columbia.edu> * support/nfs/rpcmisc.[ch]: export makesock() * utils/statd/statd.c: added longopts, added support for specifying the port to bind to on the command line. * utils/statd/statd.c: ditto, also specify port used for outgoing connections. * utils/statd/Makefile (LIBS): link with our own libnfs
* 2001-02-14 H.J. Lu <hjl@lucon.org>hjl2001-02-151-0/+1
| | | | | * utils/statd/rmtcall.c: Include <time.h>. * utils/statd/svc_run.c: Likewise.
* Added some IP address paranoia when doing callbacks to local lockd.lon2000-10-241-1/+11
|
* Fixed a bug where we were ignoring the xid in the response from a client tolon2000-10-051-1/+6
| | | | a server's SM_NOTIFY.
* Initial revisionhjl1999-10-181-0/+406