[tor-bugs] #449 [Tor Client]: dns failures prevent legitimate options being set

[Tor Bug Tracker & Wiki]

#449: dns failures prevent legitimate options being set
-------------------------+--------------------------------------------------
  Reporter:  mwenge      |       Owner:  nickm             
      Type:  defect      |      Status:  accepted          
  Priority:  minor       |   Milestone:  Tor: unspecified  
 Component:  Tor Client  |     Version:  0.2.0.2-alpha     
Resolution:  None        |    Keywords:  dns,hidden service
    Parent:              |  
-------------------------+--------------------------------------------------
Changes (by nickm):

  * status:  assigned => accepted
  * keywords:  => dns,hidden service
  * milestone:  post 0.2.1.x => Tor: unspecified


Old description:

> Outright hostname lookup failures for previously configured hidden
> services prevent other options being set
> while DNS is down.
>
> For example, I configure a hidden service redirecting to google.com while
> DNS is working. DNS subsequently stops working,
> e.g. nameserver becomes completely unreachable. If I then attempt to set
> a config option using the controller, it will
> not get set as long as tor cannot resolve the hidden service name.
>
> Rejection of hidden service configurations (and hence any subsequent or
> unrelated config change) made while tor is running
> needs to be more tolerant of lookup failures.
>
> The following attempts to validate the hidden service config currently in
> use  (and previously validated when DNS was working).
> If the validation fails, it must be because DNS is down, so the existing
> config is retained. If the user was attempting to add
> a new hidden service config, then it doesn't get added.
>
> Index: src/or/config.c
> ===================================================================
> --- src/or/config.c     (revision 10545)
> +++ src/or/config.c     (working copy)
> @@ -963,10 +963,15 @@
>      }
>    }
>
> -  if (running_tor && rend_config_services(options, 0)<0) {
> -    log_warn(LD_BUG,
> -       "Previously validated hidden services line could not be added!");
> -    return -1;
> +  if (running_tor && rend_config_services(options, 1)<0) {
> +    log_warn(LD_CONFIG,
> +       "Previously validated hidden services line no longer valid!
> Retaining existing hidden services config if there is one.");
> +  }else{
> +    if (rend_config_services(options, 0)<0){
> +        log_warn(LD_BUG,
> +           "Previously validated hidden services line could not be
> added!");
> +        return -1;
> +    }
>    }
>
>    if (running_tor) {
> @@ -2920,9 +2925,10 @@
>      }
>    }
>
> +/*
>    if (rend_config_services(options, 1) < 0)
>      REJECT("Failed to configure rendezvous options. See logs for
> details.");
> -
> +*/
>    if (parse_virtual_addr_network(options->VirtualAddrNetwork, 1,
> NULL)<0)
>      return -1;
>

>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 Outright hostname lookup failures for previously configured hidden
 services prevent other options being set
 while DNS is down.

 For example, I configure a hidden service redirecting to google.com while
 DNS is working. DNS subsequently stops working,
 e.g. nameserver becomes completely unreachable. If I then attempt to set a
 config option using the controller, it will
 not get set as long as tor cannot resolve the hidden service name.

 Rejection of hidden service configurations (and hence any subsequent or
 unrelated config change) made while tor is running
 needs to be more tolerant of lookup failures.

 The following attempts to validate the hidden service config currently in
 use  (and previously validated when DNS was working).
 If the validation fails, it must be because DNS is down, so the existing
 config is retained. If the user was attempting to add
 a new hidden service config, then it doesn't get added.

 Index: src/or/config.c
 ===================================================================
 --- src/or/config.c     (revision 10545)
 +++ src/or/config.c     (working copy)
 @@ -963,10 +963,15 @@
      }
    }

 -  if (running_tor && rend_config_services(options, 0)<0) {
 -    log_warn(LD_BUG,
 -       "Previously validated hidden services line could not be added!");
 -    return -1;
 +  if (running_tor && rend_config_services(options, 1)<0) {
 +    log_warn(LD_CONFIG,
 +       "Previously validated hidden services line no longer valid!
 Retaining existing hidden services config if there is one.");
 +  }else{
 +    if (rend_config_services(options, 0)<0){
 +        log_warn(LD_BUG,
 +           "Previously validated hidden services line could not be
 added!");
 +        return -1;
 +    }
    }

    if (running_tor) {
 @@ -2920,9 +2925,10 @@
      }
    }

 +/*
    if (rend_config_services(options, 1) < 0)
      REJECT("Failed to configure rendezvous options. See logs for
 details.");
 -
 +*/
    if (parse_virtual_addr_network(options->VirtualAddrNetwork, 1, NULL)<0)
      return -1;



 [Automatically added by flyspray2trac: Operating System: All]

--

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/449#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online