Re: [PATCH 3/3] sunrpc: reduce timeout when unregistering rpcbind registrations.

Trond Myklebust
2009-07-06T17:14:32Z

On Mon, 2009-07-06 at 12:57 -0400, Chuck Lever wrote:
> On Jul 6, 2009, at 12:40 PM, Trond Myklebust wrote:
> > On Mon, 2009-07-06 at 12:31 -0400, Chuck Lever wrote:
> >> I have considered that. AF_LOCAL in fact could replace all of our
> >> upcall mechanisms. However, portmapper, which doesn't support
> >> AF_LOCAL, is still used in some distributions.
> >
> > As could AF_NETLINK, fork(), pipes, fifos, etc... Again: why would we
> > want to saddle ourselves with rpc over AF_LOCAL?
>
> TI-RPC supports AF_LOCAL RPC transports.
>
> [cel@matisse notify-one]$ rpcinfo
> program version netid address service owner
> 100000 4 tcp6 ::.0.111 portmapper
> superuser
> 100000 3 tcp6 ::.0.111 portmapper
> superuser
> 100000 4 udp6 ::.0.111 portmapper
> superuser
> 100000 3 udp6 ::.0.111 portmapper
> superuser
> 100000 4 tcp 0.0.0.0.0.111 portmapper
> superuser
> 100000 3 tcp 0.0.0.0.0.111 portmapper
> superuser
> 100000 2 tcp 0.0.0.0.0.111 portmapper
> superuser
> 100000 4 udp 0.0.0.0.0.111 portmapper
> superuser
> 100000 3 udp 0.0.0.0.0.111 portmapper
> superuser
> 100000 2 udp 0.0.0.0.0.111 portmapper
> superuser
> 100000 4 local /var/run/rpcbind.sock portmapper
> superuser
> 100000 3 local /var/run/rpcbind.sock portmapper
> superuser
> 100024 1 udp 0.0.0.0.206.127 status 29
> 100024 1 tcp 0.0.0.0.166.105 status 29
> 100024 1 udp6 ::.141.238 status 29
> 100024 1 tcp6 ::.192.160 status 29
> [cel@matisse notify-one]$
>
> The listing for '/var/run/rpcbind.sock' is rpcbind's AF_LOCAL
> listener. TI-RPC's rpcb_foo() calls use this method of accessing the
> rpcbind database rather than going over loopback.
>
> rpcbind scrapes the caller's effective UID off the transport socket
> and uses that for authentication. Note the "owner" column... that
> comes from the socket's UID, not from the r_owner field. When a
> service is registered over the network, the owner column says
> "unknown" and basically anyone can unset it.
>
> If the kernel used AF_LOCAL to register its services, it would mean we
> would never use a network port for local rpcbind calls between the
> kernel and rpcbind, and rpcbind could automatically prevent the
> kernel's RPC services from getting unset by malicious users. If /var/
> run/rpcbind.sock isn't there, the kernel would know immediately that
> rpcbind wasn't running.

So what? You can achieve the same with any number of communication
channels (including the network). Just add a timeout to the current
'connect()' function, and set it to a low value when doing rpcbind
upcalls.

What's so special about libtirpc or rpcbind that we have to keep
redesigning the kernel to work around their limitations instead of the
other way round?

--
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com