[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #918 [Tor Relay]: bind to port 443 + wake from hibernation = exit
#918: bind to port 443 + wake from hibernation = exit
--------------------------------+-------------------------------------------
Reporter: arma | Type: defect
Status: new | Priority: normal
Milestone: Tor: 0.2.3.x-final | Component: Tor Relay
Version: 0.2.0.31 | Resolution: None
Keywords: | Parent:
--------------------------------+-------------------------------------------
Changes (by nickm):
* priority: minor => normal
* milestone: post 0.2.1.x => Tor: 0.2.3.x-final
Old description:
> <ioerror> Jan 28 22:05:50.644 [notice] Opening OR listener on
> 80.68.85.45:443
> <ioerror> Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443:
> +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]
New description:
<ioerror> Jan 28 22:05:50.644 [notice] Opening OR listener on
80.68.85.45:443
<ioerror> Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443:
+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]
--
Comment:
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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/918#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs