Red Hat Bugzilla – Bug 134425
Copy/pasting between local and remote X11 programs is broken
Last modified: 2007-11-30 17:10:50 EST
Description of problem:
With FC3-test2 (and also the latest development version of xorg-x11),
I can't copy/paste between programs running locally (using unix
sockets, I guess) and programs running on another host. When I'm
pasting from a remote program to a local one, the local one sometimes
hangs for a few seconds (this mainly seems to happen in KDE programs)
and then continues without having received any input.
Version-Release number of selected component (if applicable):
Always, and with all X programs.
Steps to Reproduce:
1. ssh -X somehost (including localhost, so it's not caused by using
different X versions)
2. start X program
3. try pasting something from the 'remote' program to a 'local' program
Nothing happens, except a hang for a few seconds in some cases.
New input in the local program.
Pasting between two different remote programs (not using the FC3-test2
X libraries), both connected to my FC3-test2 X server, does work.
Hm, I've started downgrading everything and it started working again
after downgrading openssh.. I don't quite understand how openssh can
only break one specific X protocol function: everything about
X-forwarding was working fine, just pasting failed.
I'm not sure whether this means it's an openssh bug and the component
of this bug should be changed to openssh, or if it's somehow an
incompatibility between xorg and openssh 3.9.
Does it work if you add "-Y" to your ssh options when using openssh 3.9?
It does, thanks!
There should probably be a note about this "trusted" X11 forwarding in
the release notes because X11 forwarding is pretty useless in the
default configuration now. Currently there's only a remark about the
file permissions for ~/.ssh/config.
There is a specialised case of this for emacs in bug 138617 ... Are
crashes with -X but not -Y to be filed in individual bugs for each
*** Bug 141056 has been marked as a duplicate of this bug. ***
Maybe if there were a hint of the existence of this "feature" in the
supplied config file, there would be some chance that we would notice it.
Onno this was mentioned in the release notes -
"The behavior of ssh clients that are invoked with the -X flag has changed. In
OpenSSH 3.8 and later, X11 forwarding is performed in a way that applications
run as untrusted clients by default. Previously, X11 forwarding was performed so
that applications always ran as trusted clients. Some applications may not
function properly when run as untrusted clients. To forward X11 so that
applications are run as trusted clients, invoke ssh with the -Y flag instead of
the -X flag, or set ForwardX11Trusted in the ~/.ssh/config file."
Were there some other release notes which didn't mention this?
Correct, this is not an X bug. This is a change in the upstream openssh
default operation with X clients. Since this may affect some users
configurations in a way that is unexpected, we made sure to document
this change of behaviour in Fedora Core release notes as mentioned above.
*** Bug 144067 has been marked as a duplicate of this bug. ***
*** Bug 146061 has been marked as a duplicate of this bug. ***
For those who want to know the exact difference between trusted and
untrusted, I got this from a friendly and helpful RedHat employee. :-)
From Ray Strode (firstname.lastname@example.org) on 2005-01-25 12:20 -------
-X means that ssh will use untrusted auth cookies for it's connections
to the xserver.
-Y means that ssh will use trusted auth cookies.
The xauth man page describes this:
If the trusted option is used, clients that connect
using this authorization will have full run of the display, as usual.
If untrusted is used, clients that connect using this authorization
will be considered untrusted and prevented from stealing
or tampering with data belonging to trusted clients. See the
SECURITY extension specification for full details on
the restrictions imposed on untrusted clients. The
default is untrusted.
If you have the package xorg-x11-doc installed, then you can find the
SECURITY extension specification in