the Tor project advises in: https://www.torproject.org/docs/tor-relay-debian.html.en#after to run a tor server with ORPort and DirPort at 443 and 80 respectively. This however means, that tor as a non-root user needs rights to access ports < 1024. An easy way to do this is (tested, works): setcap 'cap_net_bind_service=+ep' /usr/bin/tor" another approach is (not tested): sysctl net.inet.ip.portrange.reservedhigh=0 /me wonders if an elog info should remind the user after upgrading its tor package related to these things ?
Why inform admins when you can actually provide with changes to the ebuild + run-time configuration?
The change is just necessary if tor is configured not in the default way (where ports 9001 and 9030 are used). Well, OTOH I'm wondering if somebody should just run its own post-emerge script automatically after emerging tor ?
I don't understand the concern here. tor can bind to ports < 1024. It starts as root, binds and then drops privileges. See below: neworder ~ # cat /etc/tor/torrc User tor PIDFile /var/run/tor/tor.pid Log notice syslog DataDirectory /var/lib/tor/data ORPort 443 DirPort 81 neworder ~ # /etc/init.d/tor restart * Stopping Tor ... * Starting Tor ... neworder ~ # netstat -ntlp | grep tor tcp 0 0 0.0.0.0:81 0.0.0.0:* LISTEN 11141/tor tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN 11141/tor tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 11141/tor neworder ~ # ps aux | grep tor tor 11141 6.9 0.2 1321876 76020 ? Sl 14:52 0:03 /usr/bin/tor -f /etc/tor/torrc --runasdaemon 1 --PidFile /var/run/tor/tor.pid
I set up a tor server a week ago (amd64), where exactly this did not work. That was the reason why I realized that. I got : Sep 20 16:10:35.000 [notice] Read configuration file "/etc/tor/torrc". Sep 20 16:10:35.000 [notice] Opening Directory listener on 0.0.0.0:80 Sep 20 16:10:35.000 [warn] Could not bind to 0.0.0.0:80: Permission denied Sep 20 16:10:35.000 [notice] Opening OR listener on 0.0.0.0:443 Sep 20 16:10:35.000 [warn] Could not bind to 0.0.0.0:443: Permission denied Sep 20 16:10:35.000 [notice] Closing no-longer-configured Directory listener on 0.0.0.0:9030 Sep 20 16:10:35.000 [notice] Closing no-longer-configured OR listener on 0.0.0.0:9001 Sep 20 16:10:35.000 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Sep 20 16:10:35.000 [err] Reading config failed--see warnings above. For usage, try -h. Sep 20 16:10:35.000 [warn] Restart failed (config error?). Exiting. So I used setcap and it worked. kernel : vanilla kernel 3.16.3.
(In reply to Toralf Förster from comment #4) > I set up a tor server a week ago (amd64), where exactly this did not work. > That was the reason why I realized that. I got : > > Sep 20 16:10:35.000 [notice] Read configuration file "/etc/tor/torrc". > Sep 20 16:10:35.000 [notice] Opening Directory listener on 0.0.0.0:80 > Sep 20 16:10:35.000 [warn] Could not bind to 0.0.0.0:80: Permission denied > Sep 20 16:10:35.000 [notice] Opening OR listener on 0.0.0.0:443 > Sep 20 16:10:35.000 [warn] Could not bind to 0.0.0.0:443: Permission denied > Sep 20 16:10:35.000 [notice] Closing no-longer-configured Directory listener > on 0.0.0.0:9030 > Sep 20 16:10:35.000 [notice] Closing no-longer-configured OR listener on > 0.0.0.0:9001 > Sep 20 16:10:35.000 [warn] Failed to parse/validate config: Failed to bind > one of the listener ports. > Sep 20 16:10:35.000 [err] Reading config failed--see warnings above. For > usage, try -h. > Sep 20 16:10:35.000 [warn] Restart failed (config error?). Exiting. > > So I used setcap and it worked. > > kernel : vanilla kernel 3.16.3. Were those ports in use? Notice in my example I have `DirPort 81` and not `DirPort 80`. The reason is that i have apache on 80. If I use 80, I get a permission denied in the logs.
It is a dedicated Tor server, nothing else (except BOINC to keep the CPU happy), so all ports are free. I guess, that "/etc/init-d/tor reload" might be the culprit for the issue I had b/c at this point tor already gave away its capability, or ? Probably an "/etc/init.d/tor restart" would worked too but I tried to avoid a downtime.
(In reply to Toralf Förster from comment #6) > It is a dedicated Tor server, nothing else (except BOINC to keep the CPU > happy), so all ports are free. > > I guess, that "/etc/init-d/tor reload" might be the culprit for the issue I > had b/c at this point tor already gave away its capability, or ? > > Probably an "/etc/init.d/tor restart" would worked too but I tried to avoid > a downtime. So I'm not sure what to do with this bug right now because I can't confirm it. Can I see your config file. Remove any potentially private information.
Created attachment 386080 [details] torrc well, there are no secrets in it
This bug is more useful if you consider a hibernating relay that can't "rebind" to a reserved port. However, I don't think setting caps in an ebuild is the right way.
Okay I thought about this for a while and I'm not going to do anything. 1) I really want to avoid setting caps in an ebuild. I know we're doing that right now with things like ping and we are starting to push out stage3's with caps set, but the difference here is that it is not essential to tor's operation, and in fact sometimes undesireable, whereas it is essential for say ping with no setuid. 2) There's a lot of options for tor. Its a complex beast and I'm not going to complicate matters with a bunch of pkg_postinst() messages. People using tor as a server will have to read the upstream documentation.
