[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9258 [Tor]: Breaks in non-obvious ways when control socket path has no slashes
#9258: Breaks in non-obvious ways when control socket path has no slashes
--------------------+-------------------------------------------------------
Reporter: weasel | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor | Version: Tor: 0.2.4.15-rc
Keywords: | Parent:
Points: | Actualpoints:
--------------------+-------------------------------------------------------
Old description:
> Hi,
>
> I made a torrc and I wanted to run tor with it but it didn't work and
> didn't say why:
> {{{
> e255:weasel@defiant:~/tmp/tor$ tor -f torrc
> Jul 15 10:39:06.382 [notice] Tor v0.2.4.14-alpha (git-da7587e870f422a6)
> running on Linux with Libevent 2.0.19-stable and OpenSSL 1.0.1e.
> Jul 15 10:39:06.382 [notice] Tor can't help you if you use it wrong!
> Learn how to be safe at
> https://www.torproject.org/download/download#warning
> Jul 15 10:39:06.383 [notice] This version is not a stable Tor release.
> Expect more bugs than usual.
> Jul 15 10:39:06.383 [notice] Read configuration file
> "/home/weasel/.temp/2013-06-28/tor/torrc".
> Jul 15 10:39:06.390 [notice] Opening Socks listener on 127.0.0.1:9913
> Jul 15 10:39:06.390 [notice] Closing partially-constructed Socks listener
> on 127.0.0.1:9913
> Jul 15 10:39:06.391 [warn] Failed to parse/validate config: Failed to
> bind one of the listener ports.
> Jul 15 10:39:06.391 [err] Reading config failed--see warnings above.
> }}}
>
> My torrc:
> {{{
> DataDirectory .
> SocksPort 9913
> PidFile pid
> log debug stderr
> SafeLogging 0
> ControlSocket sock
> StrictNodes 1
> }}}
>
> Turns out that in get_parent_directory, called via
> retry_listener_ports
> connection_listener_new
> check_location_for_unix_socket
> get_parent_directory
> the path "sock" gets rejected, but nobody bothers logging about it.
>
> connection_listener_new returns a NULL conn and we tear down stuff again.
>
> It works if I specify {{{ControlSocket ./sock}}}.
New description:
Hi,
I made a torrc and I wanted to run tor with it but it didn't work and
didn't say why:
{{{
weasel@defiant:~/tmp/tor$ tor -f torrc
Jul 15 10:39:06.382 [notice] Tor v0.2.4.14-alpha (git-da7587e870f422a6)
running on Linux with Libevent 2.0.19-stable and OpenSSL 1.0.1e.
Jul 15 10:39:06.382 [notice] Tor can't help you if you use it wrong! Learn
how to be safe at https://www.torproject.org/download/download#warning
Jul 15 10:39:06.383 [notice] This version is not a stable Tor release.
Expect more bugs than usual.
Jul 15 10:39:06.383 [notice] Read configuration file
"/home/weasel/.temp/2013-06-28/tor/torrc".
Jul 15 10:39:06.390 [notice] Opening Socks listener on 127.0.0.1:9913
Jul 15 10:39:06.390 [notice] Closing partially-constructed Socks listener
on 127.0.0.1:9913
Jul 15 10:39:06.391 [warn] Failed to parse/validate config: Failed to bind
one of the listener ports.
Jul 15 10:39:06.391 [err] Reading config failed--see warnings above.
}}}
My torrc:
{{{
DataDirectory .
SocksPort 9913
PidFile pid
log debug stderr
SafeLogging 0
ControlSocket sock
StrictNodes 1
}}}
Turns out that in get_parent_directory, called via
retry_listener_ports
connection_listener_new
check_location_for_unix_socket
get_parent_directory
the path "sock" gets rejected, but nobody bothers logging about it.
connection_listener_new returns a NULL conn and we tear down stuff again.
It works if I specify {{{ControlSocket ./sock}}}.
--
Comment(by weasel):
One could argue that we should not allow relative paths
for unix domain sockets (it would require the peer to be
in the same working directory, AIUI).
I think my patch does that.
If you think we should support relative paths, then
check_location_for_unix_socket() probably needs some other fix.
Cheers
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9258#comment:1>
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