Marti Raudsepp:
Hi list,
The attached patch implements support for systemd socket activation.
For people who don't know what that is: systemd is an "init" system for Linux. Socket activation means that systemd binds all the sockets in advance, and only spawns Tor once somebody attempts to connect.
More information here: http://0pointer.de/blog/projects/socket-activation.html
I rarely use Tor, so there's no reason to have it running all the time (wasting battery on my laptop), but it's also annoying to launch it manually every time. Socket activation is ideal for this use case.
Hi Marti,
Could you open a ticket on trac?
https://trac.torproject.org/projects/tor/newticket
If you'd like to use the cypherpunks account, feel free - no need to make an account if you don't want to do so.
It seems to me that this requires a bit of documentation - for example - do you expect to run Tor as say, some-tor-user as usual (what is it on Fedora, anyway?)? How do you expect UDP to be handled as Tor does not actually support UDP (excepting DNSPort, of course). Do you expect this to be used by Tor only in client mode? Or do you expect it to be used by bridges or relays? It seems that socket activation is generally a reasonable idea - though I expect it will simply result in a Tor running nearly all of the time, no? If nothing else, I suspect it will often allow the control port controllers to easily connect - even if Tor isn't started. If anything, we may have an easy way to ensure that any authorized Tor controller may start a Tor, which is actually quite nice!
I have a bunch of questions that come to mind about anti-forensics - for example, if we restart Tor, what happens to data sitting in buffers in memory? The data stays queued, right? How do we ensure that Tor, if started for SOCKS will allow only the right configurations? Will this need to be enabled on all Tor Gnu/Linux builds or should we only enable this code for systemd supporting systems and only with a configuration option, even if we have it compiled into Tor?
Comments on the patch follow:
src/ext/README should include information on the author as well as the original location of the source.
I suspect we want to ensure that we only include mqueue.h if we have it.
There is a mix of !defined() and defined() - eg:
defined(DISABLE_SYSTEMD) !defined(SD_DAEMON_DISABLE_MQ)
I tend to think that we should assert positively what we want and what we expect - if we don't have it, we shouldn't make it confusing as to what is or isn't built.
I tend to prefer code like:
if (NULL != e) {
to code like:
if (!e) {
I also tend to be more specific with my ints - rather than int, why not uint32_t? Furthermore - will the stats leave behind a trace? What priviledges are required or set for /dev/mqueue I wonder?
Shouldn't 'foosddaemonhfoo' be a bit more... Torish? :)
Will all logging be redirected into the Tor logging subsystem?
This code seems to be optimized for your use path:
+ s = get_pending_socket(type, socktype, &addr, usePort); + if (SOCKET_OK(s)) + { + is_bound = 1; + } + else + { + log_notice(LD_NET, "Opening %s on %s", + conn_type_to_string(type), fmt_addrport(&addr, usePort)); + + s = tor_open_socket(tor_addr_family(&addr), socktype, is_tcp ? IPPROTO_TCP: IPPROTO_UDP); + if (!SOCKET_OK(s)) { + log_warn(LD_NET,"Socket creation failed: %s", + tor_socket_strerror(tor_socket_errno(-1))); + goto err;
what happens if we never take your path? Is there a performance hit?
When you apply this patch and enable debugging, do you see any warnings? On what platform did you test it where you expect it to work? How about other platforms where it shouldn't work but also shouldn't do harm?
Nick and Roger probably have stronger opinions that matter more but I just happened to arrive at the scene first...
All the best, Jacob