rpc.statd: Stop overloading sockfd in utils/statd/rmtcall.c
authorChuck Lever <chuck.lever@oracle.com>
Fri, 26 Sep 2008 20:16:09 +0000 (16:16 -0400)
committerSteve Dickson <steved@redhat.com>
Fri, 26 Sep 2008 20:16:09 +0000 (16:16 -0400)
commit572efae32f6fb311dff0e065d0d1dd527db60d0c
treec83f71cb59c891ca2061008ed4dfaf0b3a61a31f
parent7bc7c11507c853b8835e9f2ad758b8958c5607af
rpc.statd: Stop overloading sockfd in utils/statd/rmtcall.c

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>
utils/statd/rmtcall.c
utils/statd/statd.c
utils/statd/statd.h