Add support for pf divert-to sockets
Since OpenBSD 4.4, the pf firewall introduced support for divert-to rules alongside rdr-to rules. The latter form of rules translate and modify packets and requires Tor to communicate with pf via ioctls on its privileged device node /dev/pf to get the original untranslated destination address. divert-to rules however do not require access to the firewall via ioctl and the original destination address information is accessible via a getsockname(2) call.
The attached patch adds a single new TransProxyType pf-divert to signify that the firewall is operating with a divert-to rule configured to divert traffic to Tor's transparent proxy listener (discussion on the nomenclature of TransProxyTypes may be required). To avoid bloating connection_ap_get_original_destination too much, the existing logic is factored out into two additional functions, which get the destination address information via firewall (if using traditional rdr-to rules), or via the socket itself (if on Linux or using divert-to rules).
At the moment, the default TransProxyType assumes rdr-to rules and behaviour to avoid breaking existing installations. An additional TransProxyType can be added in future (pf-rdr) and the meaning of the default TransProxyType can be changed to default to assume divert rules.
Note that this means that when using pf and divert-to rules, Tor can run completely nonprivileged. This feature is not "advertised" in the documentation modification, because it has only lightly been tested and there may be other instances where Tor needs privileges that haven't been triggered in testing this patch. If admins are using rdr-to rules to begin with, they need to specify a User and start Tor as root (in order to access /dev/pf, which is mode 600 root:wheel), and making a change to use divert-to rules and remaining running Tor as root should need no other configuration changes. If admins want to run Tor as a regular nonprivileged user and do not remove the User clause, they will be prompted to do so. If it is determined there are no other instances where Tor needs privileges in this case, then this feature could be further publicised.
Trac:
Username: _x3j11