[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21054 [Core Tor/Tor]: hs: BUG() is triggered with ephemeral service on config reload
#21054: hs: BUG() is triggered with ephemeral service on config reload
-------------------------------------------------+-------------------------
Reporter: dgoulet | Owner: dgoulet
Type: defect | Status:
| needs_review
Priority: High | Milestone: Tor:
| 0.3.0.x-final
Component: Core Tor/Tor | Version: Tor:
| 0.3.0.1-alpha
Severity: Normal | Resolution:
Keywords: tor-hs, prop224, refactoring, | Actual Points:
review-group-14 |
Parent ID: | Points: 0.5
Reviewer: asn | Sponsor:
| SponsorR-can
-------------------------------------------------+-------------------------
Comment (by asn):
Replying to [comment:5 dgoulet]:
> Replying to [comment:4 asn]:
> > Initial review:
> >
> > Changes look reasonable to me. One question, why does
`circuit_get_next_service_intro_circ()` need the `start` argument?
> >
> > In the old code, we just iterated from the beginning of the
circuitlist everytime. Why do we now begin from `start`? Is it an
optimization?
>
> Yes. It is also to basically follow the `circuit_get_next_by_*` API that
uses that technique. Without it, we can't return a circuit from the middle
of the list matching our requirements and then continuing the loop at that
circuit. Else, the other options is for the function to return a list of
matching circuits. No strong preferences here, I would be fine with
either.
>
I think the way you have it is fine!
> >
> > Also, BTW I didn't manage to reproduce the original bug. How do we do
it? I started up a Tor with a normal HS, then I added an ADD_ONION, and
then I HUPed. Am I missing a step?
>
> Yes, normal service then you do `ADD_ONION NEW:BEST Port=8161` and then
HUP or `SIGNAL RELOAD`, you should hit the BUG. Btw, it won't be on
console if you setup logging and should look like this (I just reproduced
it on master):
>
> {{{
> Jan 09 09:23:44.000 [warn] tor_bug_occurred_(): Bug:
src/or/rendservice.c:839: rend_config_services: Non-fatal assertion
!(rend_service_is_ephemeral(new)) failed. (on Tor 0.3.0.1-alpha-dev
655ffeadd53833d9)
> Jan 09 09:23:44.000 [warn] Bug: Non-fatal assertion
!(rend_service_is_ephemeral(new)) failed in rend_config_services at
src/or/rendservice.c:839. Stack trace: (on Tor 0.3.0.1-alpha-dev
655ffeadd53833d9)
> [...]
> }}}
Hmm, I'm still unable to repro this with carml. I tried with unpatched
`df87812` and Tor will just successfuly HUP with no issues. Here is my
torrc:
{{{
SocksPort auto
ControlPort auto
HiddenServiceDir /tmp/hidden_service
HiddenServicePort 6667 127.0.0.1:6667
CookieAuthentication 1
CookieAuthFileGroupReadable 1
ControlPort 9051
}}}
And then I just do:
{{{
$ ./bin/carml --connect tcp:127.0.0.1:9051 -q cmd ADD_ONION NEW:BEST
Port=8161
$ ./bin/carml --connect tcp:127.0.0.1:9051 -q cmd SIGNAL RELOAD
}}}
but Tor seems to handle it just fine:
{{{
Jan 12 13:16:53.000 [notice] Tor 0.3.0.1-alpha-dev (git-df87812b41abccd6)
opening log file.
Jan 12 13:16:57.000 [notice] New control connection opened from 127.0.0.1.
Jan 12 13:16:58.000 [notice] New control connection opened from 127.0.0.1.
Jan 12 13:16:58.000 [notice] Received reload signal (hup). Reloading
config and resetting internal state.
Jan 12 13:16:58.000 [notice] Read configuration file
"/home/f/Computers/tor/mytor/../confs/bug21054".
Jan 12 13:16:58.000 [warn] CookieAuthFileGroupReadable is set, but will
have no effect: you must specify an explicit CookieAuthFile to have it
group-readable.
}}}
What am I doing wrong?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21054#comment:6>
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