tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Heads up: tmux imported into src

On Fri, Mar 11, 2011 at 03:48:16PM -0500, der Mouse wrote:

> >>> When I re-attach to tmux, I want for the tmux sessions to start
> >>> speaking to the key agent or X11 connection that I re-attached
> >>> with.  Might require that tmux proxy the connections.
> >> Strictly speaking, in each case it depends on the implementation.
> >> [...]
> > Given that it's all on the local host, you could just have tmux set
> > the SSH agent socket to be a symlink and optionally repoint it upon
> > new attaches.
> There you are, already in "depends on the implementation" territory.
> There is nothing that compels the ssh implementation to use sockets,
> much less AF_LOCAL sockets, for agent access.
> Of course, you can have tmux assume such things about the particular
> implementations in use, if you care to.  I think it would be crippling
> and therefore stupid to do so, but that's never stopped anyone yet and
> I don't expect it to start now. :-)  But I go a bit overboard in that
> direction; I'm even unhappy about making moussh's assume
> /tmp/.X11-unix/ in its X forwarding code, and as far as I know that's
> done by all X implementations running in environments that can support
> it (which certainly includes everything moussh is likely to run on).

Well, given that tmux will have to actually proxy something if one
writes a proxy for it, then I think that we can assume that tmux
would then in fact need to listen in some fashion.  If tmux has to
listen then it will need to be aware of where it should listen and
what to do when it receives requests.  This will necessarily be
implementation dependent unless there is a standard.  And so, I do
not think that it is unreasonable to suggest that a few lines of
~/.tmux.conf will solve the problem rather than hacking up tmux to
do something which is largely unnecessary and still implementation

If we consider ssh-agent and Kerberos tickets in regards to their
use in screen and tmux, we can see that the real problem is that
their location is stored in environment variables which tmux/screen
cannot alter in child processes---it is not a problem which requires
the use of proxies as all of the players obviously have access to
the underlying resources as these are mediated by UNIX UID generally.

You could make the same arguments about the X11 DISPLAY information.
This is all local, there is no need for tmux to proxy X11 but it
would be nice if tmux could let its kids know that the X server
had moved.  For X11, proxying is even less desirable as there are
many X11 applications that benefit greatly from knowing that they
are running locally and it would be nice to allow that to occur
when they are in fact running locally.

    Roland Dowdeswell                      http://Imrryr.ORG/~elric/

Home | Main Index | Thread Index | Old Index