bind to port 443 + wake from hibernation = exit
Jan 28 22:05:50.644 [notice] Opening OR listener on 80.68.85.45:443 Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443: +Permission denied Jan 28 22:05:50.645 [warn] Failed to parse/validate config: Failed +to bind one of the listener ports.
Basically if you bind to port 443 directly, and then drop privs, that's fine. When you hup, Tor will (should) correctly decide to leave that port alone since it hasn't changed and it wouldn't be able to bind it again anyway.
But when we hibernate, and then come back, we can't bind it. Currently we die.
Option one, never close it in this case. Not great, since we want to be hibernating, but not awful.
Option two, keep a separate root process around that can jumpstart Tor again. Ugh.
Option three, warn if this configuration is used, so the user can at least know.
How do we auto detect that it's a privileged port? Just "port < 1024"?
[Automatically added by flyspray2trac: Operating System: All]
Activity
changed milestone to %Tor: unspecified
A similar thing happened to me when I changed my orport to 80 and my dirport to 443 on fluxe3 (running debian). I changed the values in the torrc, reloaded Tor, and it died without notice. Option 1 wouldn't work in this case, obviously - not sure if this is something that the debian reload script could possibly detect, or if there is some other way to tell the user that Tor cannot change ports without being restarted (wihtout killing the current Tor process, of course).
I like the posix capabilities option in this case: if we're starting at root we'd want to hang on to CAP_NET_BIND_SERVICE when we setuid. This would seem to require that we use the PR_SET_KEEPCAPS option and then drop all the other relevant capabilities from our sets when we do the setuid stuff. Alternatively, we could drop the need to start as root entirely if we have file-system capabilities and Tor is explicitly given CAP_NET_BIND_SERVICE, but that's a decision the distributor or the user ought to be making.
This would only work on hosts with posix capabilities support. FWICT, that's Linux, some of the commercial Unices, and maybe one or more BSD. It's still worthwhile; we have a bunch of servers on Linux alone.
Trac:
Priority: minor to normal
Parent: N/A to N/A
Description: Jan 28 22:05:50.644 [notice] Opening OR listener on 80.68.85.45:443 Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443: +Permission denied Jan 28 22:05:50.645 [warn] Failed to parse/validate config: Failed +to bind one of the listener ports.Basically if you bind to port 443 directly, and then drop privs, that's fine. When you hup, Tor will (should) correctly decide to leave that port alone since it hasn't changed and it wouldn't be able to bind it again anyway.
But when we hibernate, and then come back, we can't bind it. Currently we die.
Option one, never close it in this case. Not great, since we want to be hibernating, but not awful.
Option two, keep a separate root process around that can jumpstart Tor again. Ugh.
Option three, warn if this configuration is used, so the user can at least know.
How do we auto detect that it's a privileged port? Just "port < 1024"?
[Automatically added by flyspray2trac: Operating System: All]
to
Jan 28 22:05:50.644 [notice] Opening OR listener on 80.68.85.45:443 Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443: +Permission denied Jan 28 22:05:50.645 [warn] Failed to parse/validate config: Failed +to bind one of the listener ports.
Basically if you bind to port 443 directly, and then drop privs, that's fine. When you hup, Tor will (should) correctly decide to leave that port alone since it hasn't changed and it wouldn't be able to bind it again anyway.
But when we hibernate, and then come back, we can't bind it. Currently we die.
Option one, never close it in this case. Not great, since we want to be hibernating, but not awful.
Option two, keep a separate root process around that can jumpstart Tor again. Ugh.
Option three, warn if this configuration is used, so the user can at least know.
How do we auto detect that it's a privileged port? Just "port < 1024"?
[Automatically added by flyspray2trac: Operating System: All]
Milestone: post 0.2.1.x to Tor: 0.2.3.x-final
Keywords: N/A deleted, N/A added-
Hrrgh. From what I can tell, for my idea above, we not only need capabilities support, but we somehow need the ability to keep capabilities across a setuid. That's prctl(PR_SET_KEEPCAPS) on Linux, and I don't know whether it's even possible elsewhere. Still worth doing even if it's only Linux, though.
There must be a way to make this work on non-Linux hosts, right?
Trac:
Actualpoints: N/A to N/A
Points: N/A to N/A 
Trac:
Username: intgr
Cc: arma,nickm,Sebastian,BarkerJr to arma, nickm, Sebastian, BarkerJr, marti@juffo.orgTrac:
Cc: arma, nickm, Sebastian, BarkerJr, marti@juffo.org to arma, nickm, Sebastian, BarkerJr, marti@juffo.org, adrelanos@riseup.net
How does this ticket compare to #8195 (moved)?
Trac:
Sponsor: N/A to N/A
Severity: N/A to Normal
Reviewer: N/A to N/Amentioned in issue #2003 (moved)
mentioned in issue #8195 (moved)
mentioned in issue #16161 (moved)
moved to tpo/core/tor#918 (closed)