From: Chuck Lever Subject: Re: [PATCH 3/3] sunrpc: reduce timeout when unregistering rpcbind registrations. Date: Mon, 6 Jul 2009 12:57:46 -0400 Message-ID: <68129579-E484-4E7E-B38D-4E14ED5A5B1D@oracle.com> References: <20090528062730.15937.70579.stgit@notabene.brown> <20090528063303.15937.62423.stgit@notabene.brown> <18992.35996.986951.556723@notabene.brown> <4A51F125.5080709@suse.de> <4A52217E.9050207@suse.de> <4E8F91E6-4E55-44BB-889B-DDB9910129BF@oracle.com> <1246898450.11267.12.camel@heimdal.trondhjem.org> Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Cc: Suresh Jayaraman , Neil Brown , Linux NFS mailing list To: Trond Myklebust Return-path: Received: from rcsinet12.oracle.com ([148.87.113.124]:65400 "EHLO rgminet12.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752326AbZGFQ57 (ORCPT ); Mon, 6 Jul 2009 12:57:59 -0400 In-Reply-To: <1246898450.11267.12.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: 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. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com