[Telepathy] Spec for file-transfer and tubes

[Mads Chr. Olesen]

On ons, 2007-03-07 at 23:19 +0100, Mads Chr. Olesen wrote:
> Hi all!
> My darcs branch is at http://www.cs.aau.dk/~mchro/telepathy-spec.tubes/

I have updated the branch with a lot of sanity fixes, etc.
The compiled spec is at
http://oldwww.cs.aau.dk/~mchro/telepathy-spec.tubes/doc/spec.html

The main points I'm unsure about are
IOStream.{Accept/RejectINETConnection, IncomingINETConnection} and the
way Tube, DTube and FileTransfer relates.

Basically the Tube interface gives Accept and Reject methods, which
"raw" tubes, DTubes and FileTransfers all need. I see three main types
of tubes:
 - Raw tubes, implements Tube, IOStream (for transporting raw data, e.g.
VNC or SSH data)
 - DTubes, implements Tube, DTube (for D-Bus communication between local
and remote apps)
 - FileTransfers, implements Tube, FileTransfer, IOStream (for
transferring files).
The requirement is that Tube.Accept needs to be called before the
"secondary" interfaces can be used (DTube, IOStream) - how is this best
written in the spec?
And what about having the same method-name on multiple interfaces on the
same object? I know it's possible in D-Bus, but is it ugly? (e.g.
GetInfo on both FileTransfer and Tube, and secondarily
GetState/GetStatus on Tube and IOStream)

> The issues I think we talked about on #telepathy was:
>  - Security against other users connecting to the sockets opened by the
> conn. mgr.
>    - For a local unix socket this can mostly be handled with file
> permissions, although this doesn't protect against malicious programs
> running as the current user.
>    - For local inet sockets there is three choices i can think of:
>      - Use some form of AUTH, where a magic key needs to be transmitted
> as the first data on the socket
>        - Rules out easy porting of legacy apps, e.g. VNC.
>      - Use no security
>        - Easy for porting legacy apps.
>      - Just thought of this one: Let the client notify the conn. mgr.
> over the tube object when it is connected, that is the client does:
>        1. Connect to socket
>        2. conn. mgr. accepts connection
>        3. client calls TubeObject.Connected
>        4. Data flows
>        This way if another program or user connects to the socket (the
> conn. mgr. should only accept one connection) the client will not call
> connected and the attacker will just have ruined the attempt, meaning
> the client should try again. Better than nothing, probably...
>          - How do we know when a legacy app. has connected?
> LD_LIBRARY_PATH hacks maybe, looking for output on STDOUT/STDERR
> indicating connection success? This needs more thinking.

I have designed the spec more or less around this. Basically i think the
client is the best to decide whether a connection is legitimate. This
way, if it is totally impossible to decide, the client can choose to
have no security. But it is the client's choice, and responsibility to
provide the best security possible (See
IOStream.IncomingINETConnection).

>  - How to advertise what tube-applications a client has
This I haven't done anything about - it will be trial and error for now.

> Comments/suggestions/flames are welcome.
If there is no raging objections, I will probably start implementing it
in Gabble within the next couple of days. Please speak up, otherwise I
will just be wasting time ;-)

-- 
Mads Chr. Olesen <shiyee at shiyee.dk>
shiyee.dk