[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