Opened 12 years ago

Closed 4 years ago

#918 closed defect (implemented)

bind to port 443 + wake from hibernation = exit

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay
Cc: arma, nickm, Sebastian, BarkerJr, marti@…, adrelanos@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

<ioerror> Jan 28 22:05:50.644 [notice] Opening OR listener on
<ioerror> Jan 28 22:05:50.644 [warn] Could not bind to
+Permission denied
<ioerror> 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]

Child Tickets

Change History (15)

comment:1 Changed 12 years ago by arma

Option three seems fine for 0.2.0.x and 0.2.1.x.

Then we should explore option one for 0.2.2.x.

comment:2 Changed 12 years ago by nickm


comment:3 Changed 12 years ago by Sebastian

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).

comment:4 Changed 11 years ago by Sebastian

Option three implemented for 0.2.1.x in a28215a150818b11e128f5f5aeb44e53a40d5af7

comment:5 Changed 11 years ago by Athaba

Could option one be used, if you add something like "KeepPort 1" is in torrc?

comment:6 Changed 11 years ago by BarkerJr

We should look at linux capabilities (libcap). Libcap allows processes to drop root privileges while retaining a few specified ones. The ntp project uses it to bind to ports after dropping privileges.

comment:7 Changed 10 years ago by nickm

Description: modified (diff)
Milestone: post 0.2.1.xTor: 0.2.3.x-final
Priority: minornormal

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.

comment:8 Changed 9 years ago by nickm

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?

comment:9 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:10 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:11 Changed 8 years ago by nickm

Component: Tor RelayTor

comment:12 Changed 7 years ago by intgr

Cc: marti@… added

comment:13 Changed 5 years ago by proper

Cc: adrelanos@… added

comment:14 Changed 4 years ago by arma

Severity: Normal

How does this ticket compare to #8195?

comment:15 Changed 4 years ago by nickm

Resolution: Noneimplemented
Status: newclosed

We now support capabilities; calling this as-done-as-it-can-get.

Note: See TracTickets for help on using tickets.