375178 - SuiteRunner and Firefox fail to start on an untrusted X connection

Status: RESOLVED WONTFIX

(Core :: Widget: Gtk, defect)

Description

[Manuel Reimer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.0.10) Gecko/20070306 SeaMonkey/1.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070220 Firefox/2.0.0.2

I'm SeaMonkey user and I've been always using my webbrowser running with a different UID as my primary account, for security reasons. This second "Web-UID" has an untrusted connection to my X-Server.

This works pretty well with SeaMonkey, but today I tried with Firefox, and Firefox fails with the following return message:

$ firefox
$ The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
  (Details: serial 451 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.)

Reproducible: Always

Steps to Reproduce:
1. You need an untrusted connection to your X-Server. You may get this using ssh -X (not -Y !)
2. Now run firefox
Actual Results:  
No start, but crash

Expected Results:  
Firefox should run with an untrusted X connection, just as SeaMonkey does. A web browser shouldn't require a trusted connection for security reasons!

Comment 1

[Samuel Sidler (old account; do not CC)]

Can you give full steps to reproduce? Walk me through it pretending I know nothing about Linux. :)

Comment 2

[Manuel Reimer]

To reproduce this bug, you need a Linux machine, which has a SSH daemon running. Now do the following:

ssh -X localhost
firefox

The first line connects yourself to your own machine using untrusted X connection. The second opens firefox on this connection.

Comment 3

[Manuel Reimer]

Updated Summary: I get the same problem now with SuiteRunner:

sandbox@linux:~$ cd seamonkey
sandbox@linux:~/seamonkey$ ./seamonkey

(seamonkey-bin:5612): Gdk-WARNING **: Connection to display :0.0 appears to be untrusted. Pointer and keyboard grabs and inter-client communication may not work as expected.
The program 'seamonkey-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
  (Details: serial 953 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.)

Comment 4

[Manuel Reimer]

A better way to reproduce this one is:

xauth -f myauth generate :0.0 MIT-MAGIC-COOKIE-1 untrusted
export XAUTHORITY=$PWD/myauth
firefox

Some distributors seem to patch SSH to not open untrusted connections for -X. The above example works in all cases.

Comment 5

[Robert Kaiser]

With the steps in bug 62814 comment #0 or comment #4 in this bug I can reproduce this.

Interestingly, xpfe-based SeaMonkey 1.1.2 runs despite some X errors, toolkit-based trunk doesn't.

trunk (debug build, but that doesn't matter) says:
-------------------------------------
robert@robert:/mnt/mozilla/projects/themes/git> /opt/seamonkey-dbg/seamonkey

(seamonkey-bin:447): Gdk-WARNING **: Connection to display :0.0 appears to be untrusted. Pointer and keyboard grabs and inter-client communication may not work as expected.
The program 'seamonkey-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
  (Details: serial 3227 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.)
nsStringStats
 => mAllocCount:              3
 => mReallocCount:            0
 => mFreeCount:               2  --  LEAKED 1 !!!
 => mShareCount:              1
 => mAdoptCount:              0
 => mAdoptFreeCount:          0
-------------------------------------

1.1.2 (release build) says:
-------------------------------------
robert@robert:~> /opt/seamonkey-1.1.2/seamonkey/seamonkey -no-remote

(seamonkey-bin:1375): Gdk-WARNING **: Connection to display :0.0 appears to be untrusted. Pointer and keyboard grabs and inter-client communication may not work as expected.
X Error: BadAtom (invalid Atom parameter) 5
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0x113
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x156
X Error: BadAtom (invalid Atom parameter) 5
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0xfa
X Error: BadAtom (invalid Atom parameter) 5
  Major opcode:  18
  Minor opcode:  0
  Resource id:  0xfa
Xlib:  extension "XInputExtension" missing on display ":0.0".
Failed to get list of devices
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x156
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x156

(Gecko:1375): Gdk-WARNING **: Coercing GDK_INPUT_ONLY toplevel window to GDK_INPUT_OUTPUT to work around bug in Xorg server

(Gecko:1375): Gdk-WARNING **: Coercing GDK_INPUT_ONLY toplevel window to GDK_INPUT_OUTPUT to work around bug in Xorg server

(Gecko:1375): Gdk-WARNING **: Coercing GDK_INPUT_ONLY toplevel window to GDK_INPUT_OUTPUT to work around bug in Xorg server
Document http://www.seamonkey.at/start loaded successfully

Comment 6

[Mats Palmgren (inactive)]

WFM, with Firefox and SeaMonkey trunk debug builds on Linux (Ubuntu-feisty).

Comment 7

[Robert Kaiser]

Mats, did you try with the steps in comment #4? I needed those to get a really untrusted connection.

Comment 8

[Mats Palmgren (inactive)]

Yes, I used the steps in comment 4 and I got the "untrusted" message
at startup.  Firefox started and I could load web pages etc, the only
problem I saw was that when parts of the window was damaged and had
to be repainted, it was painted with solid black color before the
content was painted, so it was a bit flickery, other than that it
worked fine.

Comment 9

[Robert Kaiser]

Interesting. As it's debug, I guess it's self-built.
Any non-standard build options you're using? Is GNOME support enabled? What differences might your build have to one we or the official build machines created?

Comment 10

[Shaya Potter]

this problem still exists on firefox today in ubuntu gutsy.

Comment 11

[Manuel Reimer]

Cleaning up my bugs...

My last status is, that "untrusted connections" no longer work in current X server versions at all --> WONTFIX.