Hi,
rpcbind currently silently ignores any errors that occur during
init_transport, it also happily continues if bind(2) fails for
UDP socket - it's enough if just one UDP socket is bound.
This patch makes rpcbind fail if there are problems with
setting up any transport, so we don't end up with
semi/non functional running daemon.
Signed-off-by: Jan Rękorajski <[email protected]>
diff --git a/src/rpcbind.c b/src/rpcbind.c
index 63023e1..06e5b08 100644
--- a/src/rpcbind.c
+++ b/src/rpcbind.c
@@ -179,11 +179,17 @@ main(int argc, char *argv[])
rpc_control(RPC_SVC_CONNMAXREC_SET, &maxrec);
- init_transport(nconf);
+ if (init_transport(nconf)) {
+ syslog(LOG_ERR, "%s: can't init local transport\n", argv[0]);
+ exit(1);
+ }
while ((nconf = getnetconfig(nc_handle))) {
if (nconf->nc_flag & NC_VISIBLE)
- init_transport(nconf);
+ if (init_transport(nconf)) {
+ syslog(LOG_ERR, "%s: can't init %s transport\n", argv[0], nconf->nc_netid);
+ exit(1);
+ }
}
endnetconfig(nc_handle);
@@ -276,7 +282,6 @@ init_transport(struct netconfig *nconf)
int aicode;
int addrlen = 0;
int nhostsbak;
- int checkbind;
int on = 1;
struct sockaddr *sa = NULL;
u_int32_t host_addr[4]; /* IPv4 or IPv6 */
@@ -358,7 +363,6 @@ init_transport(struct netconfig *nconf)
/*
* Bind to specific IPs if asked to
*/
- checkbind = 0;
while (nhostsbak > 0) {
--nhostsbak;
/*
@@ -425,9 +429,8 @@ init_transport(struct netconfig *nconf)
hosts[nhostsbak], nconf->nc_netid);
if (res != NULL)
freeaddrinfo(res);
- continue;
- } else
- checkbind++;
+ return 1;
+ }
(void) umask(oldmask);
/* Copy the address */
@@ -476,8 +479,6 @@ init_transport(struct netconfig *nconf)
goto error;
}
}
- if (!checkbind)
- return 1;
} else { /* NC_TPI_COTS */
if ((strcmp(nconf->nc_netid, "local") != 0) &&
(strcmp(nconf->nc_netid, "unix") != 0)) {
On Fri, 17 Sep 2010, Chuck Lever wrote:
>
> On Sep 17, 2010, at 2:12 PM, Jan Rękorajski wrote:
>
> > Hi,
> > rpcbind currently silently ignores any errors that occur during
> > init_transport, it also happily continues if bind(2) fails for
> > UDP socket - it's enough if just one UDP socket is bound.
> >
> > This patch makes rpcbind fail if there are problems with
> > setting up any transport, so we don't end up with
> > semi/non functional running daemon.
>
> Can you give us some details about why transport initialization was
> failing? There are probably some cases where we do want rpcbind to
> soldier on in spite of such troubles.
An obvious example is when address given to '-h' option isn't there,
or daemon can't bind to it for some reason.
Bind fails, but rpcbind is running as if nothing happened.
And, besides, behavior for UDP and TCP sockets is curently inconsistent
as init_transport ignores any failed UDP bind and correctly
returns error for TCP.
The only legitimate reason for ignoring errors I may see here is when
IPv6 is configured in /etc/netconfig but it's not set up on net
interfaces, but as such case is administrative mistake it should be
fixed by the admin, not the daemon.
--
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
On Mon, 20 Sep 2010, Chuck Lever wrote:
>
> On Sep 17, 2010, at 6:22 PM, Jan Rękorajski wrote:
>
[snip]
> >
> > What about TCP then? My patch was a by-product of trying to make '-h <IP>'
> > also work for tcp sockets, so if we skip unbindable addresses for UDP,
> > then will it be ok to do the same for TCP?
>
> Interesting. Now that I've actually looked at the documentation >>
> blush << rpcbind(8) explicitly says that "-h" is only for UDP. I seem
> to recall that the legacy portmapper had a problem on multi-homed
> hosts where a request was received on one interface, and the reply was
> sent out another.
>
> This is certainly a problem for datagram transports, but shouldn't be
> an issue for connection-oriented transports: the reply is always sent
> on the same connection as the request was received.
>
> Can you say a little more about why do you need "-h" to work for
> connection-oriented sockets?
I have a multihomed nfs server, and I don't want the portmapper to even
listen on an outside interface. 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. 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).
--
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
On Sep 17, 2010, at 3:04 PM, Jan Rękorajski wrote:
> On Fri, 17 Sep 2010, Chuck Lever wrote:
>
>>
>> On Sep 17, 2010, at 2:12 PM, Jan Rękorajski wrote:
>>
>>> Hi,
>>> rpcbind currently silently ignores any errors that occur during
>>> init_transport, it also happily continues if bind(2) fails for
>>> UDP socket - it's enough if just one UDP socket is bound.
>>>
>>> This patch makes rpcbind fail if there are problems with
>>> setting up any transport, so we don't end up with
>>> semi/non functional running daemon.
>>
>> Can you give us some details about why transport initialization was
>> failing? There are probably some cases where we do want rpcbind to
>> soldier on in spite of such troubles.
>
> An obvious example is when address given to '-h' option isn't there,
> or daemon can't bind to it for some reason.
> Bind fails, but rpcbind is running as if nothing happened.
The usual practice is to allow an RPC daemon to run if at least one transport can be started. That is a little more robust than failing if any one transport can't be started.
If such a failure is completely silent, then it's probably reasonable to post a notice about this in the log. But we generally like things to work automatically, if at all possible.
If rpcbind couldn't use _any_ of the specified bind addresses, I guess that is when it should fail to start. A host's networking configuration can be quite variable, especially with DHCP-configured interfaces, so these daemons have to be somewhat flexible.
> And, besides, behavior for UDP and TCP sockets is currently inconsistent
> as init_transport ignores any failed UDP bind and correctly
> returns error for TCP.
That _may_ be intentional. UDP semantics are "unreliable," so an error may be expected even at bind time. Who knows, it doesn't look very well documented.
> The only legitimate reason for ignoring errors I may see here is when
> IPv6 is configured in /etc/netconfig but it's not set up on net
> interfaces, but as such case is administrative mistake it should be
> fixed by the admin, not the daemon.
Not necessarily. ipv6.ko can be blacklisted. Should the administrator also remember to adjust /etc/netconfig in that case, or should the rpc-related daemons simply adjust automatically?
--
chuck[dot]lever[at]oracle[dot]com
On Sep 17, 2010, at 6:22 PM, Jan Rękorajski wrote:
> On Fri, 17 Sep 2010, Chuck Lever wrote:
>
>> On Sep 17, 2010, at 3:04 PM, Jan Rękorajski wrote:
>>
>>> On Fri, 17 Sep 2010, Chuck Lever wrote:
>>>
>>>>
>>>> On Sep 17, 2010, at 2:12 PM, Jan Rękorajski wrote:
[ ... snipped ... ]
>
>>> And, besides, behavior for UDP and TCP sockets is currently inconsistent
>>> as init_transport ignores any failed UDP bind and correctly
>>> returns error for TCP.
>>
>> That _may_ be intentional. UDP semantics are "unreliable," so an
>> error may be expected even at bind time. Who knows, it doesn't look
>> very well documented.
>
> What about TCP then? My patch was a by-product of trying to make '-h <IP>'
> also work for tcp sockets, so if we skip unbindable addresses for UDP,
> then will it be ok to do the same for TCP?
Interesting. Now that I've actually looked at the documentation >> blush << rpcbind(8) explicitly says that "-h" is only for UDP. I seem to recall that the legacy portmapper had a problem on multi-homed hosts where a request was received on one interface, and the reply was sent out another.
This is certainly a problem for datagram transports, but shouldn't be an issue for connection-oriented transports: the reply is always sent on the same connection as the request was received.
Can you say a little more about why do you need "-h" to work for connection-oriented sockets?
--
chuck[dot]lever[at]oracle[dot]com
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
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]
>>>
>>> What about TCP then? My patch was a by-product of trying to make '-h <IP>'
>>> also work for tcp sockets, so if we skip unbindable addresses for UDP,
>>> then will it be ok to do the same for TCP?
>>
>> Interesting. Now that I've actually looked at the documentation >>
>> blush << rpcbind(8) explicitly says that "-h" is only for UDP. I seem
>> to recall that the legacy portmapper had a problem on multi-homed
>> hosts where a request was received on one interface, and the reply was
>> sent out another.
>>
>> This is certainly a problem for datagram transports, but shouldn't be
>> an issue for connection-oriented transports: the reply is always sent
>> on the same connection as the request was received.
>>
>> Can you say a little more about why do you need "-h" to work for
>> connection-oriented sockets?
>
> I have a multihomed nfs server, and I don't want the portmapper to even
> listen on an outside interface.
Understood, but that is accomplished with firewalling, these days. Usually, NFS servers are not run on the edge of private networks unless they are serving files to public hosts.
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.
If this is NFSv4 only, ostensibly rpcbind is not needed. I know our implementation today still clings to rpcbind a bit, but theoretically at least, you could just leave it unstarted if you are only running an NFSv4 service. rpc.mountd should also allow itself to be run without starting network listeners in recent versions of nfs-utils.
I'm not necessarily arguing against the idea of adding a bind address command line option, but this _would_ be a change to long established historical behavior, and it would not be consistent with many of the other Linux RPC services I'm aware of. So, I'd like to be absolutely sure we understand what you need here, and ensure we can't address it with existing administrative controls.
> 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.
> 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.
--
chuck[dot]lever[at]oracle[dot]com
On Sep 20, 2010, at 3:03 PM, Ben Greear wrote:
> On 09/20/2010 11:53 AM, 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]
>>>>>>>
>>>>>>> What about TCP then? My patch was a by-product of trying to make '-h<IP>'
>>>>>>> also work for tcp sockets, so if we skip unbindable addresses for UDP,
>>>>>>> then will it be ok to do the same for TCP?
>>>>>>
>>>>>> Interesting. Now that I've actually looked at the documentation>>
>>>>>> blush<< rpcbind(8) explicitly says that "-h" is only for UDP. I seem
>>>>>> to recall that the legacy portmapper had a problem on multi-homed
>>>>>> hosts where a request was received on one interface, and the reply was
>>>>>> sent out another.
>>>>>>
>>>>>> This is certainly a problem for datagram transports, but shouldn't be
>>>>>> an issue for connection-oriented transports: the reply is always sent
>>>>>> on the same connection as the request was received.
>>>>>>
>>>>>> Can you say a little more about why do you need "-h" to work for
>>>>>> connection-oriented sockets?
>>>>>
>>>>> I have a multihomed nfs server, and I don't want the portmapper to even
>>>>> listen on an outside interface.
>>>>
>>>> Understood, but that is accomplished with firewalling, these days.
>>>
>>> It always was, but it's nice not needing to worry if I closed/opened all
>>> that's neccessary.
>>>
>>>> Usually, NFS servers are not run on the edge of private networks
>>>> unless they are serving files to public hosts.
>>>
>>> I would, if I could :)
>>>
>>>> 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).
>
> This is true, but if the argument against adding support to various components is
> always 'no, because the others don't support it', then we are never going
> to make progress in this direction!
I'm merely observing that none of the others support this, and have never supported it. To add support for listener binding properly, we will need to do it across the board. But I don't think the case has been made that adding the ability to bind to a specific listener address is exactly what is needed here.
The reason that these other RPC services do not support this today is because before rpcbind, it was not possible for the portmapper to direct RPC clients to specific interfaces. The new rpcbind itself adds that support via universal addresses.
However, it was decided a while ago that Linux wouldn't allow our kernel services to bind to anything but ANYADDR. So they all register as ANYADDR:port. rpcbind's ability to advertise a specific address was regarded as somehow insecure.
The Linux NFS implementation is a mix of kernel and user space services. It will take some understanding to see if and how the kernel NFS services will work together with multiple instances of user space services. I personally regard that as a difficult problem.
>> 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.
>>
>> For one thing, there appears to be more than one virtualization suite available for Linux (containers, kvm, and so on). If our NFS infrastructure (both client and server) is to be adapted for lightweight virtualization then I think we need a clear idea of how networking (host naming, interface assignment, routing, and so on) is going to work in these environments.
>>
>> Just so you (and Ben) know, I intended to add support during the recent rpc.statd rewrite for multiple hostnames and multiple interfaces, exactly for the purpose of having our NLM and NSM implementations support container-like virtualization. This idea was NACK'd.
>
> I'm sorry to hear it was NACK'd, but even if so, I think it's not a reason to
> reject other changes that start adding support for binding to IPs.
I don't have the authority to reject anything. I'm simply explaining the history, and requesting that we slow down and think about some of the details.
If we regard binding to specific listener addresses as a good way to proceed, I think we have an architecturally complex task ahead of us. Having a common agreed-upon vision in front of us is important to getting the details right. I don't think we should just start hacking this stuff in while the NFS community and its reviewers don't have a clear vision about what is going to happen eventually.
--
chuck[dot]lever[at]oracle[dot]com
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]
>>>>>
>>>>> What about TCP then? My patch was a by-product of trying to make '-h <IP>'
>>>>> also work for tcp sockets, so if we skip unbindable addresses for UDP,
>>>>> then will it be ok to do the same for TCP?
>>>>
>>>> Interesting. Now that I've actually looked at the documentation >>
>>>> blush << rpcbind(8) explicitly says that "-h" is only for UDP. I seem
>>>> to recall that the legacy portmapper had a problem on multi-homed
>>>> hosts where a request was received on one interface, and the reply was
>>>> sent out another.
>>>>
>>>> This is certainly a problem for datagram transports, but shouldn't be
>>>> an issue for connection-oriented transports: the reply is always sent
>>>> on the same connection as the request was received.
>>>>
>>>> Can you say a little more about why do you need "-h" to work for
>>>> connection-oriented sockets?
>>>
>>> I have a multihomed nfs server, and I don't want the portmapper to even
>>> listen on an outside interface.
>>
>> Understood, but that is accomplished with firewalling, these days.
>
> It always was, but it's nice not needing to worry if I closed/opened all
> that's neccessary.
>
>> Usually, NFS servers are not run on the edge of private networks
>> unless they are serving files to public hosts.
>
> I would, if I could :)
>
>> 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).
[ ... 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?
>>> 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.
For one thing, there appears to be more than one virtualization suite available for Linux (containers, kvm, and so on). If our NFS infrastructure (both client and server) is to be adapted for lightweight virtualization then I think we need a clear idea of how networking (host naming, interface assignment, routing, and so on) is going to work in these environments.
Just so you (and Ben) know, I intended to add support during the recent rpc.statd rewrite for multiple hostnames and multiple interfaces, exactly for the purpose of having our NLM and NSM implementations support container-like virtualization. This idea was NACK'd.
--
chuck[dot]lever[at]oracle[dot]com
On 09/20/2010 11:53 AM, 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]
>>>>>>
>>>>>> What about TCP then? My patch was a by-product of trying to make '-h<IP>'
>>>>>> also work for tcp sockets, so if we skip unbindable addresses for UDP,
>>>>>> then will it be ok to do the same for TCP?
>>>>>
>>>>> Interesting. Now that I've actually looked at the documentation>>
>>>>> blush<< rpcbind(8) explicitly says that "-h" is only for UDP. I seem
>>>>> to recall that the legacy portmapper had a problem on multi-homed
>>>>> hosts where a request was received on one interface, and the reply was
>>>>> sent out another.
>>>>>
>>>>> This is certainly a problem for datagram transports, but shouldn't be
>>>>> an issue for connection-oriented transports: the reply is always sent
>>>>> on the same connection as the request was received.
>>>>>
>>>>> Can you say a little more about why do you need "-h" to work for
>>>>> connection-oriented sockets?
>>>>
>>>> I have a multihomed nfs server, and I don't want the portmapper to even
>>>> listen on an outside interface.
>>>
>>> Understood, but that is accomplished with firewalling, these days.
>>
>> It always was, but it's nice not needing to worry if I closed/opened all
>> that's neccessary.
>>
>>> Usually, NFS servers are not run on the edge of private networks
>>> unless they are serving files to public hosts.
>>
>> I would, if I could :)
>>
>>> 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).
This is true, but if the argument against adding support to various components is
always 'no, because the others don't support it', then we are never going
to make progress in this direction!
> 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.
>
> For one thing, there appears to be more than one virtualization suite available for Linux (containers, kvm, and so on). If our NFS infrastructure (both client and server) is to be adapted for lightweight virtualization then I think we need a clear idea of how networking (host naming, interface assignment, routing, and so on) is going to work in these environments.
>
> Just so you (and Ben) know, I intended to add support during the recent rpc.statd rewrite for multiple hostnames and multiple interfaces, exactly for the purpose of having our NLM and NSM implementations support container-like virtualization. This idea was NACK'd.
I'm sorry to hear it was NACK'd, but even if so, I think it's not a reason to
reject other changes that start adding support for binding to IPs.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 09/20/2010 02:53 PM, 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]
>>>>>>
>>>>>> What about TCP then? My patch was a by-product of trying to make '-h <IP>'
>>>>>> also work for tcp sockets, so if we skip unbindable addresses for UDP,
>>>>>> then will it be ok to do the same for TCP?
>>>>>
>>>>> Interesting. Now that I've actually looked at the documentation >>
>>>>> blush << rpcbind(8) explicitly says that "-h" is only for UDP. I seem
>>>>> to recall that the legacy portmapper had a problem on multi-homed
>>>>> hosts where a request was received on one interface, and the reply was
>>>>> sent out another.
>>>>>
>>>>> This is certainly a problem for datagram transports, but shouldn't be
>>>>> an issue for connection-oriented transports: the reply is always sent
>>>>> on the same connection as the request was received.
>>>>>
>>>>> Can you say a little more about why do you need "-h" to work for
>>>>> connection-oriented sockets?
>>>>
>>>> I have a multihomed nfs server, and I don't want the portmapper to even
>>>> listen on an outside interface.
>>>
>>> Understood, but that is accomplished with firewalling, these days.
>>
>> It always was, but it's nice not needing to worry if I closed/opened all
>> that's neccessary.
>>
>>> Usually, NFS servers are not run on the edge of private networks
>>> unless they are serving files to public hosts.
>>
>> I would, if I could :)
>>
>>> 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).
>
> [ ... 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?
>
>>>> 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.
>
> For one thing, there appears to be more than one virtualization suite available for Linux (containers, kvm, and so on). If our NFS infrastructure (both client and server) is to be adapted for lightweight virtualization then I think we need a clear idea of how networking (host naming, interface assignment, routing, and so on) is going to work in these environments.
>
> Just so you (and Ben) know, I intended to add support during the recent rpc.statd rewrite for multiple hostnames and multiple interfaces, exactly for the purpose of having our NLM and NSM implementations support container-like virtualization. This idea was NACK'd.
>
Would you mind gigging out and post the pointer to the discussion
where your you are talking about... Just to refresh us as to the
ins and outs as to why it got NACKed... Because I do agree we
has to become much more virt friendly since virtualization
is the future.... So with this perspective, maybe we should take
another look at your patches...
steved.
On Sep 17, 2010, at 2:12 PM, Jan Rękorajski wrote:
> Hi,
> rpcbind currently silently ignores any errors that occur during
> init_transport, it also happily continues if bind(2) fails for
> UDP socket - it's enough if just one UDP socket is bound.
>
> This patch makes rpcbind fail if there are problems with
> setting up any transport, so we don't end up with
> semi/non functional running daemon.
Can you give us some details about why transport initialization was failing? There are probably some cases where we do want rpcbind to soldier on in spite of such troubles.
> Signed-off-by: Jan Rękorajski <[email protected]>
>
> diff --git a/src/rpcbind.c b/src/rpcbind.c
> index 63023e1..06e5b08 100644
> --- a/src/rpcbind.c
> +++ b/src/rpcbind.c
> @@ -179,11 +179,17 @@ main(int argc, char *argv[])
>
> rpc_control(RPC_SVC_CONNMAXREC_SET, &maxrec);
>
> - init_transport(nconf);
> + if (init_transport(nconf)) {
> + syslog(LOG_ERR, "%s: can't init local transport\n", argv[0]);
> + exit(1);
> + }
>
> while ((nconf = getnetconfig(nc_handle))) {
> if (nconf->nc_flag & NC_VISIBLE)
> - init_transport(nconf);
> + if (init_transport(nconf)) {
> + syslog(LOG_ERR, "%s: can't init %s transport\n", argv[0], nconf->nc_netid);
> + exit(1);
> + }
> }
> endnetconfig(nc_handle);
>
> @@ -276,7 +282,6 @@ init_transport(struct netconfig *nconf)
> int aicode;
> int addrlen = 0;
> int nhostsbak;
> - int checkbind;
> int on = 1;
> struct sockaddr *sa = NULL;
> u_int32_t host_addr[4]; /* IPv4 or IPv6 */
> @@ -358,7 +363,6 @@ init_transport(struct netconfig *nconf)
> /*
> * Bind to specific IPs if asked to
> */
> - checkbind = 0;
> while (nhostsbak > 0) {
> --nhostsbak;
> /*
> @@ -425,9 +429,8 @@ init_transport(struct netconfig *nconf)
> hosts[nhostsbak], nconf->nc_netid);
> if (res != NULL)
> freeaddrinfo(res);
> - continue;
> - } else
> - checkbind++;
> + return 1;
> + }
> (void) umask(oldmask);
>
> /* Copy the address */
> @@ -476,8 +479,6 @@ init_transport(struct netconfig *nconf)
> goto error;
> }
> }
> - if (!checkbind)
> - return 1;
> } else { /* NC_TPI_COTS */
> if ((strcmp(nconf->nc_netid, "local") != 0) &&
> (strcmp(nconf->nc_netid, "unix") != 0)) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
chuck[dot]lever[at]oracle[dot]com
On 09/20/2010 09:21 AM, 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]
>>>>
>>>> What about TCP then? My patch was a by-product of trying to make '-h<IP>'
>>>> also work for tcp sockets, so if we skip unbindable addresses for UDP,
>>>> then will it be ok to do the same for TCP?
>>>
>>> Interesting. Now that I've actually looked at the documentation>>
>>> blush<< rpcbind(8) explicitly says that "-h" is only for UDP. I seem
>>> to recall that the legacy portmapper had a problem on multi-homed
>>> hosts where a request was received on one interface, and the reply was
>>> sent out another.
>>>
>>> This is certainly a problem for datagram transports, but shouldn't be
>>> an issue for connection-oriented transports: the reply is always sent
>>> on the same connection as the request was received.
>>>
>>> Can you say a little more about why do you need "-h" to work for
>>> connection-oriented sockets?
>>
>> I have a multihomed nfs server, and I don't want the portmapper to even
>> listen on an outside interface.
>
> Understood, but that is accomplished with firewalling, these days. Usually, NFS servers are not run on the edge of private networks unless they are serving files to public hosts.
>
> 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.
Simply not listening to an IP may be more convenient (and perform better)
than setting up firewalls.
Binding also allows one to specify which interface to use if you have
two interfaces on the same subnet.
I posted a patch a week or two ago that allowed the kernel components
to bind to specific IPs. I'm glad to see I'm not the only one interested
in this, and hopefully we can start making all parts of NFS able to bind
to specific IPs when requested.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, 17 Sep 2010, Chuck Lever wrote:
> On Sep 17, 2010, at 3:04 PM, Jan Rękorajski wrote:
>
> > On Fri, 17 Sep 2010, Chuck Lever wrote:
> >
> >>
> >> On Sep 17, 2010, at 2:12 PM, Jan Rękorajski wrote:
> >>
> >>> Hi,
> >>> rpcbind currently silently ignores any errors that occur during
> >>> init_transport, it also happily continues if bind(2) fails for
> >>> UDP socket - it's enough if just one UDP socket is bound.
> >>>
> >>> This patch makes rpcbind fail if there are problems with
> >>> setting up any transport, so we don't end up with
> >>> semi/non functional running daemon.
> >>
> >> Can you give us some details about why transport initialization was
> >> failing? There are probably some cases where we do want rpcbind to
> >> soldier on in spite of such troubles.
> >
> > An obvious example is when address given to '-h' option isn't there,
> > or daemon can't bind to it for some reason.
> > Bind fails, but rpcbind is running as if nothing happened.
>
> The usual practice is to allow an RPC daemon to run if at least one
> transport can be started. That is a little more robust than failing
> if any one transport can't be started.
>
> If such a failure is completely silent, then it's probably reasonable
> to post a notice about this in the log. But we generally like things
> to work automatically, if at all possible.
It does syslog all problems with creating sockets.
> If rpcbind couldn't use _any_ of the specified bind addresses, I guess
> that is when it should fail to start. A host's networking
> configuration can be quite variable, especially with DHCP-configured
> interfaces, so these daemons have to be somewhat flexible.
Ok, I can live with that, it just seemed bad to me that those errors got
ignored.
> > And, besides, behavior for UDP and TCP sockets is currently inconsistent
> > as init_transport ignores any failed UDP bind and correctly
> > returns error for TCP.
>
> That _may_ be intentional. UDP semantics are "unreliable," so an
> error may be expected even at bind time. Who knows, it doesn't look
> very well documented.
What about TCP then? My patch was a by-product of trying to make '-h <IP>'
also work for tcp sockets, so if we skip unbindable addresses for UDP,
then will it be ok to do the same for TCP?
--
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
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]
> >>>
> >>> What about TCP then? My patch was a by-product of trying to make '-h <IP>'
> >>> also work for tcp sockets, so if we skip unbindable addresses for UDP,
> >>> then will it be ok to do the same for TCP?
> >>
> >> Interesting. Now that I've actually looked at the documentation >>
> >> blush << rpcbind(8) explicitly says that "-h" is only for UDP. I seem
> >> to recall that the legacy portmapper had a problem on multi-homed
> >> hosts where a request was received on one interface, and the reply was
> >> sent out another.
> >>
> >> This is certainly a problem for datagram transports, but shouldn't be
> >> an issue for connection-oriented transports: the reply is always sent
> >> on the same connection as the request was received.
> >>
> >> Can you say a little more about why do you need "-h" to work for
> >> connection-oriented sockets?
> >
> > I have a multihomed nfs server, and I don't want the portmapper to even
> > listen on an outside interface.
>
> Understood, but that is accomplished with firewalling, these days.
It always was, but it's nice not needing to worry if I closed/opened all
that's neccessary.
> Usually, NFS servers are not run on the edge of private networks
> unless they are serving files to public hosts.
I would, if I could :)
> 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 this is NFSv4 only, ostensibly rpcbind is not needed. I know our
> implementation today still clings to rpcbind a bit, but theoretically
> at least, you could just leave it unstarted if you are only running an
> NFSv4 service. rpc.mountd should also allow itself to be run without
> starting network listeners in recent versions of nfs-utils.
That's all good, but some still need portmapper for other services.
> I'm not necessarily arguing against the idea of adding a bind address
> command line option, but this _would_ be a change to long established
> historical behavior, and it would not be consistent with many of the
> other Linux RPC services I'm aware of. So, I'd like to be absolutely
> sure we understand what you need here, and ensure we can't address it
> with existing administrative controls.
I understand your concerns, but I have problem imagining someone that
had to limit UDP bind not wanting to also limit TCP.
> > 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.
> > 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?
--
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
On Sep 21, 2010, at 7:55 AM, Steve Dickson wrote:
>
>
> On 09/20/2010 02:53 PM, 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]
>>>>>>>
>>>>>>> What about TCP then? My patch was a by-product of trying to make '-h <IP>'
>>>>>>> also work for tcp sockets, so if we skip unbindable addresses for UDP,
>>>>>>> then will it be ok to do the same for TCP?
>>>>>>
>>>>>> Interesting. Now that I've actually looked at the documentation >>
>>>>>> blush << rpcbind(8) explicitly says that "-h" is only for UDP. I seem
>>>>>> to recall that the legacy portmapper had a problem on multi-homed
>>>>>> hosts where a request was received on one interface, and the reply was
>>>>>> sent out another.
>>>>>>
>>>>>> This is certainly a problem for datagram transports, but shouldn't be
>>>>>> an issue for connection-oriented transports: the reply is always sent
>>>>>> on the same connection as the request was received.
>>>>>>
>>>>>> Can you say a little more about why do you need "-h" to work for
>>>>>> connection-oriented sockets?
>>>>>
>>>>> I have a multihomed nfs server, and I don't want the portmapper to even
>>>>> listen on an outside interface.
>>>>
>>>> Understood, but that is accomplished with firewalling, these days.
>>>
>>> It always was, but it's nice not needing to worry if I closed/opened all
>>> that's neccessary.
>>>
>>>> Usually, NFS servers are not run on the edge of private networks
>>>> unless they are serving files to public hosts.
>>>
>>> I would, if I could :)
>>>
>>>> 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).
>>
>> [ ... 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?
>>
>>>>> 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.
>>
>> For one thing, there appears to be more than one virtualization suite available for Linux (containers, kvm, and so on). If our NFS infrastructure (both client and server) is to be adapted for lightweight virtualization then I think we need a clear idea of how networking (host naming, interface assignment, routing, and so on) is going to work in these environments.
>>
>> Just so you (and Ben) know, I intended to add support during the recent rpc.statd rewrite for multiple hostnames and multiple interfaces, exactly for the purpose of having our NLM and NSM implementations support container-like virtualization. This idea was NACK'd.
>>
> Would you mind gigging out and post the pointer to the discussion
> where your you are talking about... Just to refresh us as to the
> ins and outs as to why it got NACKed... Because I do agree we
> has to become much more virt friendly since virtualization
> is the future.... So with this perspective, maybe we should take
> another look at your patches...
Some of the multi-home patches were actually part of the IPv6 overhaul, so I'd guess we are about halfway there already. IPv6 support requires decent multi-home support, because many hosts (going forward) will have at least an IPv4 and an IPv6 address. There were just a few (user space and kernel, lockd and statd) that Trond had some trouble with, and we may be able to reach a consensus on how to fix those.
We have a great opportunity in two weeks to walk through this topic, together as a group, in person. Any old statd patches will probably have to be reworked anyway, since I think some of the details of virtualization support in NFS are probably different now that we have talked through it a bit.
--
chuck[dot]lever[at]oracle[dot]com