[Telepathy] Spec for file-transfer and tubes

[Robert McQueen]

Mads Chr. Olesen wrote:
> man, 19 03 2007 kl. 17:08 +0000, skrev Dafydd Harries:
>> - should we offer a private bus for data transfer?
> I suggest: I'm not sure this is necessary. A local socket provides the
> same functionality, and is much easier/as easy to use for clients.

This question was based on the idea that we'd have some kind of
file/stream object which would initially appear on the starter bus (ie
the one you use to talk to the CM usually) in order to meet the "bus is
forwarded to a remote CM" use-case. If the client is local to the CM, a
local socket makes sense, so I agree that the private bus stuff seems a
bit redundant.

Even if the CM is remote, it's likely some proxy will exist and can
understand Telepathy, so this proxy could arrange to forward the sockets
for you (imagining something with libssh on the client end, it could
make a new ssh channels for every file you transferred or tube you joined).

>> - how should authentication work for local sockets?
> I suggest: Use file permissions on local sockets.
> Pros:
> - Only correct user's apps can connect
> Cons:
> - ...

Unfortunately chmodding Unix sockets is Linux-specific. To protect Unix
sockets on other architectures using permissions, you need to make
subdirectories which contain them, which get left behind and clutter up
/tmp when stuff crashes or whatever, and get you temporary file naming
issues. Instead D-Bus uses credential passing, where a struct describing
the current user is "attached" to some data (a NUL byte) and sent, via
the kernel verifying it's truthfulness, to the bus daemon. So anyone can
connect to the Unix socket, but if it's not the right local user they
get disconnected immediately.

>> - is IOStream suitably general for file transfers and tubes?
> I suggest: Yes. The CM should implement at least TCP-sockets, and e.g.
> libtp should provide wrappers for using a local unix socket through to
> the TCP-socket.
> Pros:
> - Provides same interface for both in the CM => code re-use
> - Provides maximum flexibility for clients
> Cons:
> - libtp needs to have extra code for emulating the client's requested
> method

At the moment in the tube spec we don't actually have a D-Bus object
which attempts to transmit the tube or file data sent/received over any
kind of bus (either a starter or a private bus), and as I said in the
first paragraph, I'm not convinced it's hugely useful to enter into that
complexity just for the (currently hypothetical) remote CM use case.

I don't understand what you mean with emulation. If a client is using
libtelepathy, it's coding against the Telepathy API already, so has no
legacy code to worry about. You don't need any emulation inside
libtelepathy to make a TCP socket look like a Unix socket or vice versa.
I don't think that makes any sense.

That leaves us with local Unix sockets, which we know that we can secure
somehow, and TCP sockets which we can't very easily. My conclusion is
that the CM shouldn't implement TCP sockets unless that we *really* need
them. For me, that would be in order to support launching a TCP legacy
application for use with a Tube.

For seperate reasons (code re-use, insulation from wire protocol,
multi-user semantics, etc), we've decided that rather than a normal Unix
socket, these non-legacy brave new Telepathy clients should talk D-Bus
to each other. If that's wrong or troublesome for people, we can
consider providing a normal Unix socket too.

>>  - do we really need local UDP/TCP connections, or are local Unix
>> sockets
>>    sufficient?
> I suggest: No, not necessarily. However, we need TCP connections for
> remote CMs anyway, and can wrap a local Unix socket to a TCP-connection,
> so I would say CMs must implement TCP-connections and can implement Unix
> sockets.

Why do we need TCP connections for remote CMs? I think it's easier for
CMs to implement one thing, ie Unix sockets which are more useful to us
on local clients. The thing which connects us to the bus that the remote
CM is running on can also connect us to the remote CM's Unix sockets,
and do any converting between Unix sockets/TCP as necessary.

>>  - how will this work if the connection manager is not on the same
>> machine as
>>    the client?
> I suggest: Let's support this.

Let's not rule this out, but let's not make our job too complicated
either... :D

> Am I missing something? I'll try to write it up as a spec sometime soon.

Well, as you can see I'm in favour of D-Tubes for tubes, which is the
spec we've merged and started implementing, and a Unix socket for file
transfers. We'll need a protocol where we throw a NUL byte over the
socket so we can exchange credentials, and libtp can help our clients do
that.

Remote CMs can be supported by proxying these remote Unix sockets to
local Unix sockets somehow (which is similar to how ssh X forwarding
works, and how a ssh D-Bus forwarding would probably work).

If clients have real need for tubes which aren't D-Tubes, we can add
that to the spec, and re-use the file transfer Unix socket code for tube
Unix sockets.

If we have the need for exporting a legacy TCP service over a tube, we
can add a little API for this. Unlike transferring a file, I don't think
security is *hugely* important for such TCP services, because these
legacy TCP protocols will all have their own authentication (eg VNC) or
not need it (eg http).

I think that in my mind, the person who offered the tube would have a
TCP server (ie listen() somewhere) and tell the port to the CM when
offering the tube. Once the remote party accepts the tube, their CM
opens a listen() socket. Every connection to it would then result in a
connection being tunneled to the initiator's TCP service, much like ssh
-L behaves. In the case of eg VNC, the params dictionary could contain a
username and password, or similar.

How does all that sound?

Regards,
Rob