commit 7b2c856785b226ee20867450daa8436c3020e950 Author: Yawning Angel yawning@schwanenlied.me Date: Mon Oct 10 20:57:45 2016 +0000
Bug 20261: Treat AF_UNIX addresses as equal when comparing them.
This is a kludge to deal with the fact that `tor_addr_t` doesn't contain `sun_path`. This currently ONLY happens when circuit isolation is being checked, for an isolation mode that is force disabled anyway, so the kludge is "ugly but adequate", but realistically, making `tor_addr_t` and the AF_UNIX SocksPort code do the right thing is probably the better option. --- src/common/address.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/src/common/address.c b/src/common/address.c index 6799dd6..dd2164e 100644 --- a/src/common/address.c +++ b/src/common/address.c @@ -1041,6 +1041,10 @@ tor_addr_copy_tight(tor_addr_t *dest, const tor_addr_t *src) * Different address families (IPv4 vs IPv6) are always considered unequal if * <b>how</b> is CMP_EXACT; otherwise, IPv6-mapped IPv4 addresses are * considered equivalent to their IPv4 equivalents. + * + * As a special case, all AF_UNIX addresses are always considered equal + * since tor_addr_t currently does not contain the information required to + * make the comparison. */ int tor_addr_compare(const tor_addr_t *addr1, const tor_addr_t *addr2, @@ -1114,6 +1118,18 @@ tor_addr_compare_masked(const tor_addr_t *addr1, const tor_addr_t *addr2, return 0; } } + case AF_UNIX: + /* HACKHACKHACKHACKHACK: + * tor_addr_t doesn't contain a copy of sun_path, so it's not + * possible to comapre this at all. + * + * Since the only time we currently actually should be comparing + * 2 AF_UNIX addresses is when dealing with ISO_CLIENTADDR (which + * is diesabled for AF_UNIX SocksPorts anyway), this just returns 0. + * + * See: #20261. + */ + return 0; default: /* LCOV_EXCL_START */ tor_fragile_assert();