Expose the Eliot logs in a safer way

[exarkun]

Currently it's possible to have a daemon write Eliot logs to a file. This is great for development and debugging against non-sensitive nodes. However, Eliot logs may contain privileged information (fURLs, caps, filenames, etc).

It may not always be desirable to have this information written to disk. Instead, it should be possible to publish it using a purely in-memory scheme. Of course, one solution for this would be to write the file to an in-memory filesystem (eg a Linux tmpfs mount). However, this is minimally usable and it's unclear how portable it is. Instead, provide a cross-platform Tahoe-LAFS-native solution.

[exarkun]

One possibility would be to have the Tahoe-LAFS node listen on a local TCP port and accept one (or more?) client connections to that server. Clients would have Eliot logs streamed to them. Some kind of authentication would be required to prevent attackers with local access from reading the logs. A possibility there is to use the existing api_auth_token as a credential.

Pros:

• TCP servers like this are a breeze with Twisted

Cons:

• It's impossible to reliably listen on a specified TCP port number (it might be in use already).
• It's difficult to communicate an ephemeral port number to another piece of automation (for example, GridSync?).

[exarkun]

Another possibility would be to reverse the client/server roles of the previous option.

Pros:

• The need for authentication is probably eliminated. A consumer listens on an address and then tells Tahoe-LAFS that address. The OS enforces single listener (there are flags to monkey with this; don't use them).
• TCP clients like this aren't quite as easy as TCP servers but at least the implementation only needs to be in Tahoe-LAFS
• It's easy to pass the TCP port number in to Tahoe-LAFS from another piece of automation.

Cons:

• It only enables a single consumer per Tahoe-LAFS process (unless you extend it to stream logs to multiple servers...)

[exarkun]

Another possibility would be to pass a file descriptor in to the Tahoe-LAFS process and stream logs to that.

Pros:

• Authentication is not necessary. You have a pipe between two processes and no one else has a chance to get in the way.
• You don't have to listen on any TCP ports at all, slightly reducing your attack surface.
• Twisted has good support for passing file descriptors to new processes on POSIX.

Cons:

• Twisted has bad or no support for passing file descriptors to new processes on Windows.
• Even more tightly bound to the concept of a single consumer.
• The only possibility for reconnection if you lose the pipe is restarting the Tahoe-LAFS process (but there may be no real reason to lose the pipe).

[exarkun]

Another possibility is to extend the existing http-based status interface to expose this information. There are probably many flavors of this general idea. There could be a resource you poll, a resource you "long poll", server-sent events (sse), WebSockets?, etc.

For any of these http-based interfaces, authentication is required - eg with api_auth_token.

Pros:

• Ask anyone: the web has won.
• Supports multiple consumers.
• Comes with built-in versioning to support future changes (new behavior? new url.)
• Autobahn should make this easy.

Maybe-Pros:

• Comes with straightforward TLS for confidentiality (but do you ever actually want to expose this to non-localhost?)
• Other WebSocket? features like compression and framing

Non-Cons:

• Tahoe-LAFS already transitively depends on Autobahn via magic-wormhole

Cons:

• High complexity (software involved, concepts involved, computational & memory requirements) option. Resulting public interface inherits a lot of this.

[exarkun]

On discussion with meejah and cypher, option in comment 4 seems like it ticks the most good boxes. We need to investigate whether you can POST an Upgrade request to switch to WebSockets? (so we can include authentication) - so far looks like we can - and whether/how we can put an Autobahn resource into our Nevow resource tree.

[meejah]

It seems that "officially" you cannot use POST to start a WebSocket? connection (RFC says "start with GET" and Autobahn code does check the method).

It is no problem to put an Autobahn WebSocketResource into the Nevow tree and make a successful client connection (also with Autobahn).

Two options for authentication: we "do nothing" until the client-side WebSocket? sends an authentication of some kind, or include the token in a header (e.g. Authorization:) and reject any connections that don't have it. The latter is probably easier.

[exarkun]

​https://github.com/tahoe-lafs/tahoe-lafs/pull/584

[exarkun]

Fixed in ​https://github.com/tahoe-lafs/tahoe-lafs/commit/42c5bc1e2f117e7db2cea06985fcf124c8c39642