forward the dbus session?

Brian J. Murrell brian at interlinx.bc.ca
Sun Feb 15 01:59:10 EST 2009


On Sat, 14 Feb 2009 15:27:51 +0100, Peter Stuge wrote:
> 
> I seem to recall previous posts about forwarding UNIX sockets. Maybe it
> was already implemented by someone? Search archive and bugzilla.

That would be cool.  But the implementation of having a local ssh connect 
to a UNIX socket and relay to/from it to/from a tunnel is trivial.

> SendEnv in ssh_config and AcceptEnv in sshd_config can be used to push
> out environment variables, but I guess you want to customize a little on
> the server to update the socket name.

Yeah.  And I don't want the feature to be any more intrusive and 
laborious than X forwarding already is, which does not require the 
{Send,Accept}Env settings on either end.

> I guess the objection is simply that dbus is too fluffy for anyone to
> jump on it,

Objection, or just that nobody has done it yet?

> but if you can provide a patch which turns out to be very
> small and if you can demonstrate/explain how the feature is a great
> benefit for users then it has a better chance of being included anyway.

Well, the benefit is clear to anyone who understands what DBUS is and 
what it's good for.  My immediate need however is that Totem won't work 
properly without a DBUS connection to the display it's displaying on.  
Arguably this is a bug in Totem, yes, but this is just one example.

But in general, DBUS is the glue that binds disparate desktop 
applications together, allowing them to send and receive signals.  It 
would be nice if a desktop app started on a remote machine but displaying 
to my local desktop could interact with my desktop as if I ran it locally.

Given that there have not been any strong rejections of the idea (yet) 
maybe I will spend an hour or two and hack up a patch.

b.




More information about the openssh-unix-dev mailing list