Re: [PATCH] rpcbind: don't ignore bind and init_transport errors

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

 



On Mon, 20 Sep 2010, Chuck Lever wrote:

> 
> On Sep 20, 2010, at 12:48 PM, Jan RÄkorajski wrote:
> 
> > On Mon, 20 Sep 2010, Chuck Lever wrote:
> > 
> >> 
> >> On Sep 20, 2010, at 11:31 AM, Jan RÄkorajski wrote:
> >> 
> >>> On Mon, 20 Sep 2010, Chuck Lever wrote:
> >>> 
> >>>> 
> >>>> On Sep 17, 2010, at 6:22 PM, Jan RÄkorajski wrote:
> >>>> 
[snip]
> > 
> >> None of NFS's RPC daemons allow you to set a bind address, with one
> >> exception.  rpc.statd allows one to specify a "bind address" in the
> >> form of a host name for reasons specific to the NSM protocol.
> > 
> > I may be wrong here, but maybe it's because it was always portmapper
> > doing the binding, so if portmapper couldn't then no one thought of
> > adding this to RPC daemons.
> 
> If rpc.mountd is running on a host, and rpcbind is not, it doesn't
> matter.  A port scanner can still find and attack the open mountd
> port.  The best and safest approach, IMO, is to use a firewall, and
> then test it with a remote port scanner service.  Our rpcbind
> implementation has tcp_wrapper already built in, for instance, but I
> use the iptables firewall in Fedora 13 (and, I keep RPC services on
> hosts inside the firewall, not on the firewall itself).

You're right, but try to see that rpcbind is not just a part of NFS
implementation.  It is an RPC port mapper daemon that happens to be
mostly used by NFS and is maintained by NFS people.  So rpc.mountd
security should be a separate issue, especially if it can run without a
portmapper.

> [ ... snipped ... ]
> 
> >>> Second thing is a host for vservers
> >>> (http://linux-vserver.org), I need to run portmapper in guests but
> >>> rpcbind listening on INADDR_ANY is not letting me.
> >> 
> >> Can you say more?  Maybe it's a bug.
> > 
> > It's more of a design flaw, vserver is an isolation techique, and if I
> > bind to some port on INADDR_ANY on host then I can't bind to that
> > port on guests. I don't know the implementation details, but network
> > interfaces other than lo are not (maybe can't be) isolated enough.
> 
> The problem is the guest listeners get EADDRINUSE, or equivalent,
> since they are sharing a network namespace with the host?

It appears so, sorry that I can't elaborate more on this.

> >>> And finally it's good
> >>> to be consistent, it's strange to me that someone may want to limit only
> >>> the UDP part of portmapper (modulo network issues you mentioned).
> >> 
> >> "-h" was added to address an issue specific to Linux UDP sockets.
> >> It's not a feature, but a bug fix that is UDP-specific.  TCP doesn't
> >> need this bug fix.
> > 
> > Of course, but why not change a bugfix into a feature?
> 
> If we want to add this feature properly, we will have to change a
> broad range of user space components.  Therefore it will be a
> non-trivial undertaking.

IMO adding this to rpcbind won't hurt anybody, it's simple and may be a good
starting point to work on the rest of the daemons.  Besides I do have rpcbind
with my patch running and NFS and other RPC services are working just fine.

-- 
Jan RÄkorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux