Bug#805167: suggested rpcbind.socket

[Anders Hammarquist]

[didn't think to subscribe to this bug, so I didn't see this until now]

On Thu, 24 Dec 2015 10:57:02 +0100 Laurent Bigonville  wrote:
> > nis can't be the only rpc service that talks to rpcbind over inet rather
> > than unix sockets, and custom rpc services are probably more likely
> > to use inet. The path of least surprise is clearly to start rpcbind
> > on inet socket access as well.
> >
> > You could argue that it should only start on access from localhost,
> > unfortunately binding the loopback address from systemd prevents
> > rpcbind from receiving remote calls, so that doesn't work.
> >
> > Therefore I propose /lib/systemd/system/rpcbind.socket be changed as
> > follows:
> >
> > - --- /lib/systemd/system/rpcbind.socket.orig 2015-12-14
> 20:19:36.018585993 +0100
> > +++ /lib/systemd/system/rpcbind.socket 2015-12-14 20:14:32.905673475
> +0100
> > @@ -3,6 +3,11 @@
> >
> > [Socket]
> > ListenStream=/run/rpcbind.sock
> > +ListenStream=[::]:111
> > +ListenStream=0.0.0.0:111
> > +ListenDatagram=[::]:111
> > +ListenDatagram=0.0.0.0:111
> > +BindIPv6Only=ipv6-only
> >
> > [Install]
> > WantedBy=sockets.target
>
> Has this been tested? I actually don't think this is enough, the code
> that manage the fd passed by systemd should also be adjusted. Not 100%
> sure, but I'm afraid that if the activation is done by the inet socket,
> the unix one will not work (and the opposite)

Yes, I'm running it on my nis clients, and I haven't seen any adverse
effects. I suppose that clients trying to connect to the unix socket
fall back to tcp or udp if it fails, but I think I checked with rpcinfo
that I could talk to rpcbind over all transports. I can check again to
be certain (though not right now).

/Anders

Bug#805167: suggested rpcbind.socket

[Laurent Bigonville]

> nis can't be the only rpc service that talks to rpcbind over inet rather
> than unix sockets, and custom rpc services are probably more likely
> to use inet. The path of least surprise is clearly to start rpcbind
> on inet socket access as well.
>
> You could argue that it should only start on access from localhost,
> unfortunately binding the loopback address from systemd prevents
> rpcbind from receiving remote calls, so that doesn't work.
>
> Therefore I propose /lib/systemd/system/rpcbind.socket be changed as
> follows:
>
> - --- /lib/systemd/system/rpcbind.socket.orig 2015-12-14 
20:19:36.018585993 +0100
> +++ /lib/systemd/system/rpcbind.socket 2015-12-14 20:14:32.905673475 
+0100

> @@ -3,6 +3,11 @@
>
> [Socket]
> ListenStream=/run/rpcbind.sock
> +ListenStream=[::]:111
> +ListenStream=0.0.0.0:111
> +ListenDatagram=[::]:111
> +ListenDatagram=0.0.0.0:111
> +BindIPv6Only=ipv6-only
>
> [Install]
> WantedBy=sockets.target

Has this been tested? I actually don't think this is enough, the code 
that manage the fd passed by systemd should also be adjusted. Not 100% 
sure, but I'm afraid that if the activation is done by the inet socket, 
the unix one will not work (and the opposite)

Bug#805167: suggested rpcbind.socket

[Anders Hammarquist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

nis can't be the only rpc service that talks to rpcbind over inet rather
than unix sockets, and custom rpc services are probably more likely
to use inet. The path of least surprise is clearly to start rpcbind
on inet socket access as well.

You could argue that it should only start on access from localhost,
unfortunately binding the loopback address from systemd prevents
rpcbind from receiving remote calls, so that doesn't work.

Therefore I propose /lib/systemd/system/rpcbind.socket be changed as
follows:

- --- /lib/systemd/system/rpcbind.socket.orig 2015-12-14 20:19:36.018585993 
+0100
+++ /lib/systemd/system/rpcbind.socket  2015-12-14 20:14:32.905673475 +0100
@@ -3,6 +3,11 @@
 
 [Socket]
 ListenStream=/run/rpcbind.sock
+ListenStream=[::]:111
+ListenStream=0.0.0.0:111
+ListenDatagram=[::]:111
+ListenDatagram=0.0.0.0:111
+BindIPv6Only=ipv6-only
 
 [Install]
 WantedBy=sockets.target

/Anders
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWbxcvAAoJENr9WVlAi3ub8cMQAKlHfLV6iR9IpirlvJZLFy2z
dFyI/v+a05u7Dre/2ae22E1fruRuNttUZDddVujR52r6jqHdDPERUt5eAUmhVAd2
iV54+7dUhSos6vBdyk674Mdd14EZl05ur8a0+y6s42MyMVyJusUw8JRMxDZ3obOK
rF8w5184TrnCTqSgKCx4ApmOQJ7yP9EMHTgThOqx/1Mu9oK+3eviaF1pko2S+3O/
1XhonndOeKgMeLznqzZOIwdx2QN9wwpTAxU/of1VE6Zgm0PKHjGmGZNxnox4A2VS
1uAeNdTPPC41voO4aw7xJnhn7rHS9I/ZGcsmJHds2+TlMb0wSLL3LGC5BwTLbSWA
gCUo0JuSGtOF/gBhFLzsBv9Z1lNnAmwd1DXKEBEe3vyJvlG4sZo2xqdzhreERPwz
hT2HtGayow8QaH0yC12zHVtciHo8GcQ06+0yUSh9poDooux7dWfdleQlB9sBD7Kq
gw228wBu3ClPX20tWxb9Cu1GPvW8rKr08L41ohgH8mFVGLO04GeWHREQgH9BDH82
ad6zfnCwNuqePb1gZkj4TeZG5LKanH8c2gLww1RBMf9v+MsMTDbXNPkg7CrvuXHc
czyiGWKzeiy5gW5Z0htm2VY/3gaf8+zIGjb3ufbNhy/u3/HbqukTOq+e1UKhxtvh
lufmo+eSfRkpnft+2GvJ
=Apc5
-END PGP SIGNATURE-