Searched hist:203710 (Results 1 - 3 of 3) sorted by relevance
| /freebsd-11.0-release/usr.sbin/rpcbind/ | ||
| H A D | rpcbind.h | diff 203710 Tue Feb 09 18:15:16 MST 2010 imp When you have multiple addresses on the same network on different interfaces (such as when you are part of a carp pool), and you run rpcbind -h to restrict which interfaces have rpc services, rpcbind can none-the-less return addresses that aren't in the -h list. This patch enforces the rule that when you specify -h on the command line, then services returned from rpcbind must be to one of the addresses listed in -h, or be a loopback address (since localhost is implicit when running -h). The root cause of this is the assumption in addrmerge that there can be only one interface that matches a given network IP address. This turns out not to be the case. To retain historical behavior, I didn't try to fix the routine to prefer the address that the request came into, since I didn't know the side effects that might cause in the normal case. My quick analysis suggests that it wouldn't be a problem, but since this code is tricky I opted for the more conservative patch of only restricting the reply when -h is in effect. Hence, this change will have no effect when you are running rpcbind without -h. Reviewed by: alfred@ Sponsored by: iX Systems MFC after: 2 weeks |
| H A D | rpcbind.c | diff 203710 Tue Feb 09 18:15:16 MST 2010 imp When you have multiple addresses on the same network on different interfaces (such as when you are part of a carp pool), and you run rpcbind -h to restrict which interfaces have rpc services, rpcbind can none-the-less return addresses that aren't in the -h list. This patch enforces the rule that when you specify -h on the command line, then services returned from rpcbind must be to one of the addresses listed in -h, or be a loopback address (since localhost is implicit when running -h). The root cause of this is the assumption in addrmerge that there can be only one interface that matches a given network IP address. This turns out not to be the case. To retain historical behavior, I didn't try to fix the routine to prefer the address that the request came into, since I didn't know the side effects that might cause in the normal case. My quick analysis suggests that it wouldn't be a problem, but since this code is tricky I opted for the more conservative patch of only restricting the reply when -h is in effect. Hence, this change will have no effect when you are running rpcbind without -h. Reviewed by: alfred@ Sponsored by: iX Systems MFC after: 2 weeks |
| H A D | util.c | diff 203710 Tue Feb 09 18:15:16 MST 2010 imp When you have multiple addresses on the same network on different interfaces (such as when you are part of a carp pool), and you run rpcbind -h to restrict which interfaces have rpc services, rpcbind can none-the-less return addresses that aren't in the -h list. This patch enforces the rule that when you specify -h on the command line, then services returned from rpcbind must be to one of the addresses listed in -h, or be a loopback address (since localhost is implicit when running -h). The root cause of this is the assumption in addrmerge that there can be only one interface that matches a given network IP address. This turns out not to be the case. To retain historical behavior, I didn't try to fix the routine to prefer the address that the request came into, since I didn't know the side effects that might cause in the normal case. My quick analysis suggests that it wouldn't be a problem, but since this code is tricky I opted for the more conservative patch of only restricting the reply when -h is in effect. Hence, this change will have no effect when you are running rpcbind without -h. Reviewed by: alfred@ Sponsored by: iX Systems MFC after: 2 weeks |
Completed in 71 milliseconds