[tor-dev] RFC patch: systemd socket activation

[Jacob Appelbaum]

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