default to /var/run/tor/control and /var/run/tor/control.authcookie

[adrelanos]

How does corridor-data open a Tor control connection?

If $TOR_CONTROL_SOCKET is nonempty (e.g. /var/run/tor/control), use it. Otherwise, connect to $TOR_CONTROL_HOST (defaults to localhost) on port $TOR_CONTROL_PORT (defaults to 9051).

If $TOR_CONTROL_COOKIE_AUTH_FILE is nonempty (e.g. /var/run/tor/control.authcookie), use it. Otherwise, pass $TOR_CONTROL_PASSWD (defaults to an empty password).

Defaulting to localhost:9051 with an empty Tor control password is not great. I doubt any distribution / user has such settings set.

I guess defaulting to /var/run/tor/control and /var/run/tor/control.authcookie has a higher chance of working for a bigger amount of people out of the box. By now, all distributions should have updated to providing Tor control cookies authentication by default?

Implementing this ticket would ease Debian packaging. (https://github.com/rustybird/corridor/issues/10) Otherwise the Debian packaging would have to add a patch to add a "debian specific" configuration file /etc/corridor.conf/50-debian.conf.

TOR_CONTROL_SOCKET=/var/run/tor/control
TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control.authcookie

[rustybird]

Defaulting to localhost:9051 with an empty Tor control password is not great.

Agreed. I wanted to use cookie authentication from the beginning, but the lack of standardized paths is off-putting. For example, using the Debian specific /var/run/tor/control.authcookie instead of tor's (sort of) default /var/lib/tor/control_auth_cookie doesn't seem right. It's true, the /var/run tmpfs is a more appropriate place for ephemeral files, but this should be fixed upstream maybe?

[adrelanos]

Rusty Bird:

Defaulting to localhost:9051 with an empty Tor control password is not great.

Agreed. I wanted to use cookie authentication from the beginning, but the lack of standardized paths is off-putting. For example, using the Debian specific /var/run/tor/control.authcookie instead of tor's (sort of) default /var/lib/tor/control_auth_cookie doesn't seem right. It's true, the /var/run tmpfs is a more appropriate place for ephemeral files, but this should be fixed upstream maybe?

It surely should be fixed upstream if it was an upstream issue. I was going to create a ticket, but no need. I doubt Tor is using "/var/lib/tor/control" by The Tor Project default. The following search query rarely shows any results: site:torproject.org "/var/lib/tor/control"

[rustybird]

I doubt Tor is using "/var/lib/tor/control" by The Tor Project default

It's only ControlAuthCookie, which effectively defaults to <tor data directory>/control_auth_cookie:

https://gitweb.torproject.org/tor.git/tree/src/or/control.c?id=8917c4f19fccbe26ccea78b7fdb6d4730ef017c4#n6344

Then it can be enabled using CookieAuthentication 1. (It seems unfortunate that ControlSocket doesn't use the same logic; here there's no default, and setting the path is the same as enabling it. But the exact mechanism is less important than somehow establishing a convention of where the file is supposed to go.)

[adrelanos]

The Tor Project upstream bug report: set Tor Control Authcookie default file location from /var/lib/tor/control.authcookie to /var/run/tor/control.authcookie https://trac.torproject.org/projects/tor/ticket/19572

[adrelanos]

Can you implement this ticket please? Or do you wish to wait until this gets fixed upstream?

Or should I send a pull request for a Debian specific configuration snippet?

(Untested for now.)

if test -f /etc/os-release ; then
   . /etc/os-release
   if [ "$ID" = "debian" ]; then
      TOR_CONTROL_SOCKET=/var/run/tor/control
      TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control.authcookie
   fi
fi

[rustybird]

Otherwise the Debian packaging would have to add a patch to add a "debian specific" configuration file /etc/corridor.conf/50-debian.conf.

Can you do it this way for now? I'd like to at least wait for a response from upstream (though not necessarily until they implement it).

[adrelanos]

Yes. Done.