[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#621471: Protocol selection for access to rpcbind is broken



On Fri, 2011-04-08 at 04:51 +0100, Ben Hutchings wrote:
> Package: libtirpc1
> Version: 0.2.1-1
> X-Debbugs-Cc: 621471@bugs.debian.org
> 
> On Fri, 2011-04-08 at 03:24 +0100, Ben Hutchings wrote:
> > libtirpc really does a terrible job of protocol fallback.
> > 
> > When trying to connect to rpcbind/portmap, it iterates over the
> > protocols listed in /etc/netconfig (nice choice of name, oh yeah) and
> > tries to create a socket for each in turn.  Then it selects the last
> > protocol for which that succeeded (yes, the last, not the first).
> > 
> > Only then does it try to connect.  So there is no fallback at all for
> > connection.
> > 
> > I'm attaching a patch to fix connection fallback, but unfortunately it
> > is not sufficient to make svc_reg() with portmap.
> 
> OK, it seems that the libtirpc caller has to do arrange to portmap by
> calling svc_reg() and then svc_register().  (Or just give up on portmap
> altogether.)
[...]

Unfortunately that's another trap.  svc_register() is backward-
compatible at the C API level but not the protocol level.  And it looks
like it would be a lot of work to add rpcbind/portmapper fallback
support in libtirpc itself.

Given that the portmapper protocol appears to have been deprecated in
favour of rpcbind in 1995 (RFC 1833), I'm happy to declare it obsolete.
I'm surprised that we've left it so long.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: