Bug 209452 - Gedit can't handle multiple logins from same user
Gedit can't handle multiple logins from same user
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gedit (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
: Reopened
: 246261 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-05 09:35 EDT by Sam Knuth
Modified: 2013-04-15 04:46 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2008-0019
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-16 09:12:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of gedit crash (2.44 MB, text/plain)
2006-10-05 09:38 EDT, Sam Knuth
no flags Details

  None (edit)
Description Sam Knuth 2006-10-05 09:35:35 EDT
Description of problem:
It seems that gnome applications can not handle multiple logins from the same
user. For example, if you have gedit opened on your local machine, and then ssh
-X into that machine from another machine and try to open gedit there, the local
instance of gedit crashes, and the remote instance wont start at all.

Version-Release number of selected component (if applicable):
RHEL 5 Beta 1

How reproducible:
Always

Steps to Reproduce:
* Open a GEDIT window on the local machine
* SSH into that machine from another machine with X forwarding
* Open GEDIT on the remote machine
  
Actual results:
* Gedit crashes on the local machine
* Gedit does not open on the remote machine
* This error appears on the SSH terminal on the remote machine:

[samfw@xander ~]$ gedit
X11 connection rejected because of wrong authentication.

Expected results:
* Gedit says up on the local machine
* Gedit open on the remote machine

Additional info:

I don't think this is limited to GEDIT - I believe it's a general gnome/gconf issue.
Comment 1 Sam Knuth 2006-10-05 09:38:16 EDT
Created attachment 137818 [details]
strace of gedit crash

Attaching an strace of first gedit instance on the local machine. This instance
crashes when the second instance is opened on the same machine by the same user
via an ssh -X session.
Comment 2 Ray Strode [halfline] 2006-10-05 13:20:58 EDT
what makes you think this isn't a gedit specific issue?
Comment 3 Sam Knuth 2006-10-05 15:27:44 EDT
sorry - let's work this as a gedit issue for now. I have a theory that might be
a bit premature about other gnome applications, but I need more testing for that.
Comment 5 RHEL Product and Program Management 2006-11-14 15:21:06 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 6 Ray Strode [halfline] 2006-12-06 11:12:38 EST
Hi Sam,

I just noticed you said that you tried ssh -X.  ssh -X isn't really that useful
of a command anymore.  For the most part it's been superceded by ssh -Y (which
has the same semantics of ssh -X from RHEL4).  If you try the sam experiment but
with ssh -Y, does it work better?
Comment 7 Sam Knuth 2006-12-14 12:31:10 EST
Hi Ray,

Sorry for the delay here. It doesn't make a difference if it's -Y or -X - the
exact same results happen. This is in RHEL 5 Beta 2 or FC6 GA with latest errata.

-Sam
Comment 8 RHEL Product and Program Management 2007-06-05 16:51:57 EDT
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Since this
bugzilla is in a component that is not approved for the current
release, it has been closed with resolution deferred.  You may
reopen this bugzilla for consideration in the next release.
Comment 11 Ray Strode [halfline] 2007-11-12 15:52:48 EST
*** Bug 246261 has been marked as a duplicate of this bug. ***
Comment 12 Ray Strode [halfline] 2007-11-13 15:10:06 EST
devack.
Comment 14 Ray Strode [halfline] 2007-12-18 16:39:14 EST
So here's what happens:

1) the first gedit instance starts up in factory mode
2) the second gedit instance notices the first one is being a factory
3) it then tells the first instance, "you create the window instead of me" and exits
4) The first gedit instance tries to open the ssh display
5) it promptly fails because it doesn't know the displays generated password
(auth cookie)

Some of this factory handling code happens with in a set of convenience
functions called libbacon that gets cut-and-paste into various projects. 
Bastien wrote libbacon, so I'm CCing him.

We have a few options:

a) fix libbacon to forward the auth cookie along to the server instance, and get
the server instance to add the auth cookie to its list of known cookies
b) change libbacon to have a new step between 3) and 4) above which makes the
server ack to the client "Okay, I'm able to do what you're asking of me" or nack
to the client "I tried to take over for you but couldn't"
c) disable the factory code entirely in the ssh forwarding case

both a) and b) are fairly invasive and require changing libbacon itself (which
we don't really want to fork just for gedit), so c) seems like the best option.
 The factory doesn't really offer any advantages in this case anyway.

One gotcha is, how do we know gedit's being forwarded?  I think ssh sets some
environment variables we could check, but another alternative is to see if
DISPLAY is setup to use a tcp address instead of socket address.

The latter is the approach I came up with.  It's not a great fix, but it's
fairly uninvasive.

Should be fixed in gedit-2.16.0-7.el5

Marking MODIFIED for QA
Comment 15 Bastien Nocera 2007-12-18 16:58:02 EST
c) is definitely the right option. I have some pretty horrible piece of code in
Totem to detect if we are on a local display or not, and I haven't heard any
complaints.

Want me to cook something up?
Comment 16 Ray Strode [halfline] 2007-12-18 17:15:46 EST
if you have tested code that's less hacky than the 

if (getenv("DISPLAY")[0] != ':') return FALSE;

equivalent I have now, I'd love it if you'd cook something up :-)
Comment 17 Bastien Nocera 2007-12-18 17:47:20 EST
See totem_display_is_local():
http://svn.gnome.org/viewvc/totem/trunk/src/backend/video-utils.c?view=markup

And just return NULL in bacon_message_connection_new() if display isn't local.
Comment 18 Ray Strode [halfline] 2007-12-19 09:37:50 EST
Hmm, that's pretty close to what I already built.  The main difference is your
code would let 

DISPLAY=localhost:[0-9] 

continue to use the factory (which is fine).  Still, the change probably isn't
worth a rebuild.
Comment 22 errata-xmlrpc 2008-01-16 09:12:13 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0019.html

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