This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 134425 - Copy/pasting between local and remote X11 programs is broken
Copy/pasting between local and remote X11 programs is broken
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
: 141056 144067 146061 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-02 04:55 EDT by Onno Molenkamp
Modified: 2007-11-30 17:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-29 00:17:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Onno Molenkamp 2004-10-02 04:55:13 EDT
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):

6.8.0-4, 6.8.1-4.

How reproducible:

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
  
Actual results:

Nothing happens, except a hang for a few seconds in some cases.

Expected results:

New input in the local program.

Additional info:

Pasting between two different remote programs (not using the FC3-test2
X libraries), both connected to my FC3-test2 X server, does work.
Comment 1 Onno Molenkamp 2004-10-02 15:05:06 EDT
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.
Comment 2 Warren Togami 2004-10-05 00:50:33 EDT
Does it work if you add "-Y" to your ssh options when using openssh 3.9?
Comment 3 Onno Molenkamp 2004-10-05 03:32:26 EDT
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.
Comment 4 Sitsofe Wheeler 2004-11-28 15:31:25 EST
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
program?
Comment 5 Bob T. 2004-11-28 22:08:59 EST
*** Bug 141056 has been marked as a duplicate of this bug. ***
Comment 6 Bob T. 2004-11-28 22:12:34 EST
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.
Comment 7 Sitsofe Wheeler 2004-11-29 03:48:34 EST
Onno this was mentioned in the release notes - 
http://fedora.redhat.com/docs/release-notes/fc3/x86/ :

"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?
Comment 8 Mike A. Harris 2004-11-29 07:05:56 EST
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.

Thanks Sitsofe.
Comment 9 Pontus Fuchs 2005-01-07 04:08:01 EST
*** Bug 144067 has been marked as a duplicate of this bug. ***
Comment 10 Eric Hopper 2005-01-24 20:50:29 EST
*** Bug 146061 has been marked as a duplicate of this bug. ***
Comment 11 Eric Hopper 2005-01-25 12:34:09 EST
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 (rstrode@redhat.com)  on 2005-01-25 12:20 -------

Hi,

-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 

/usr/share/doc/xorg-x11-doc-*/Xext/security.PS.gz

Note You need to log in before you can comment on or make changes to this bug.