Bug 146061

Summary:	Remote gnome-terminal through ssh tunnel fails
Product:	[Fedora] Fedora	Reporter:	Eric Hopper <eric-bugs>
Component:	gnome-terminal	Assignee:	Ray Strode [halfline] <rstrode>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-02-21 14:08:02 EST	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Description Eric Hopper 2005-01-24 20:40:41 EST

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5)
Gecko/20041110 Firefox/1.0

Description of problem:
Whenever I try to use ssh (or any other remote X method for that
matter) to start up a gnome-terminal (or several other gnome programs)
it always fails with a BadAtom error.


Version-Release number of selected component (if applicable):
gnome-terminal-2.7.3-1

How reproducible:
Always

Steps to Reproduce:
1.ssh -X <some host> gnome-terminal


Actual Results:
The program 'gnome-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
  (Details: serial 67 error_code 5 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error()
function.)


Expected Results:  I expect a nice gnome-terminal running on the
remote host to appear on my screen.

Additional info:

Comment 1 Eric Hopper 2005-01-24 20:44:09 EST

ssh -X seems to work for 'dia'.  'gimp' made it through the 'upgrade
from 2.0 to 2.2' dialog, and now it consistently crashes.

Comment 2 Ray Strode [halfline] 2005-01-24 20:48:11 EST

What happens if you use ssh -Y instead of ssh -X?

Comment 3 Eric Hopper 2005-01-24 20:50:22 EST


*** This bug has been marked as a duplicate of 134425 ***

Comment 4 Eric Hopper 2005-01-24 21:25:59 EST

Can you point me at any good documentation describing the exact
difference between -X and -Y?  I'm just curious.

Comment 5 Ray Strode [halfline] 2005-01-25 12:20:32 EST

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

Comment 6 Eric Hopper 2005-01-25 12:31:35 EST

Thanks a whole bunch.  I spent about an hour googling last night and
while I was able to find the -Y option, I couldn't find any
explanations of what it did, just vague hints.

I'm going to add this to the main report so people who are hunting for
it are more likely to find the explanation.

Comment 7 Red Hat Bugzilla 2006-02-21 14:08:02 EST

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.