337510 - Seamonkey's running from DIFFERENT machines using a common display effect each other

Status: RESOLVED DUPLICATE of bug 151863

(SeaMonkey :: General, defect)

Description

[Donald R. Laster jr.]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060405 SeaMonkey/1.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060405 SeaMonkey/1.0.1

I run seamonkey 1.0.1 (currently) on a system called saia with the display set to elfa:0.0.  I installed on elfa seamonkey 1.5a and have using elfa's display (elfa:0.0).

If I start 1.0.1 first and then start 1.5a the about on the 1.5a windows is

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060405 SeaMonkey/1.0.1

and not the 1.5a information.  If I start 1.5a first the about will be the 1.5a window (at least initially).

If I terminate either invokation with FILE QUIT (i.e. cntl-Q) BOTH applications terminate even though they are running on two DIFFERENT systems.

The two systems are on the same subnet and are set to be equivalent in via the host files.

This is a serious bug.  Invokations of seamonkey running from different systems using the same display should not effect each other.

I am also wondering if this is related to some of the seamonkey starting problems.  Also bug number 122698 may be related in some way.


Reproducible: Always

Steps to Reproduce:
1.Open a xterm on system ELFA (b) and rlogin into SAIA (a)
2.Set the DISPLAY to ELFA as elfa:0.0
3.Start seamonkey on saia with the display on ELFA
4.Open another xterm on system ELFA
5.Set the DISPLAY to elfa:0.0
6.Start seamonkey from ELFA
7.Exit (i.e. Cntl-Q) either seamonkey - both with terminate

I have been noticing this problem ever since I added 1.5a and started doing some testing of it and was finally able to figure out what was happening.

Actual Results:  
Both seamonkey executions, running on two different systems, exit.

Expected Results:  
The seamonkey instructed to termiate should exit.  The other seamonkey running on the other system should have stayed running.

I am running the distribution version of seamonkey 1.0.1 on saia and the 1.5a of seamonkey from the download site.

Linux distributions are the builds directory from the CDs

saia 

Linux saia 2.4.20 #6 Sun Mar 30 17:11:31 EST 2003 i686 unknown unknown GNU/Linux

elfa

Linux elfa 2.4.29 #6 Thu Jan 20 16:30:37 PST 2005 i686 unknown unknown GNU/Linux

For rlogin purposes the two systems are set as equivalent in the hosts files (hosts.equiv).

The executables are only sharing the DISPLAY nothing else.

I have not tried running older versions of Seamonkey (1.0), Mozilla (i.e. 1.8) or Firefox but am wondering if some of the start up problems that were reported are related to this.

I have duplicated this 5 times intentionally.  Exiting EITHER invocation of Seamonkey terminates both invocation.

This is a serious bug in my opinion.  Seamonkey's running from different systems and sharing the same display should not effect each other execution.

I select a severity of Critical because the other unrelated execution of seamonkey from the other system is being terminated when it should not be terminating.

This may also qualify as a security issue as well.

Comment 1

[Donald R. Laster jr.]

This is the about information from seamonkey 1.5a

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060505 SeaMonkey/1.5a

If 1.5a is started first the about page appears to stay as 1.5a.

Comment 2

[Andrew Schultz]

You don't have 2 apps from different machines affecting one another.  You have a single instance.  Current trunk builds looks for an existing instance during startup and open a new window (or a new tab with the given URL, etc, depending on prefs) off the existing instance.  The second startup then exits.  This is by design (see bug 122698).  If you actually want two instances, start up the second time with something like

seamonkey -no-remote
or
define MOZ_NO_REMOTE in your environment.
or
have different profile names for the different computers and start up with
seamonkey -P profilename

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

Comment 3

[Donald R. Laster jr.]

  While I agree this turns out to be a duplicate of 122698 I believe this is an serious security problem.  If a  display is being shared and two people happen to have the same profile name (i.e. brown - Tom Brown and Cindy Brown) the wrong browser will get used.  The browser used should always be the browser the user is actually executing.

  Another possibility is that if a Browser Window is minimized from a compromised system on a system doing the display then attempts to start the Broswer on the display system will result in the browser from the compromised system.  

  I do not believe that when starting the browser it should look for windows from other systems that may be displayed on the same display.  A display is for displaying windows not selecting which program to use from different systems which the user has not selected.  Different system for the same user will likely have different settings.  In addition security rules dictate that the command (in this case the browser) execute is the one the user chose to execute.

  The default for this I believe should always be to have MOZ_NO_REMOTE set.