80051 - run multiple instances of mozilla when installed from RPM

Status: RESOLVED FIXED

(Core Graveyard :: X-remote, enhancement)

Description

[Andrew Taylor]

The /usr/bin/mozilla shell script that is installed from the 0.9 RPM release
does not allow distinct users to run seperate copies of mozilla.

To reproduce:
login as user xxx
run /usr/bin/mozilla
open shell and su to user yyy
run /usr/bin/mozilla

Result:
the shell script opens a second window on the mozilla instance of xxx.

Expected result:
a new instance of mozilla started for yyy

Comment 1

[timeless]

did root run regxpcom && regchrome? [hrm, do rpm's require this]

Comment 2

[Andrew Taylor]

Ran regxpcom and regchrome as root and tried again with same results.  The
/usr/lib/mozilla shell script works as follows:
 - run mozilla with '-remote openURL(...)'
 - if that fails, exec mozilla

The problem is another user's mozilla will accept the '-remote openURL()', and
thus enforces sort of a "one-mozilla per X display" rule.

Comment 3

[timeless]

Yep, we don't support that :) there are a bunch of bugs about this, they should 
be marked as blocking this bug, and would lead to this bug being treated as 
future.

Comment 4

[Christopher Blizzard (:blizzard)]

If you can talk to the X display you can try and open a new window.  This is a
feature, not a bug.

Comment 5

[Christopher Blizzard (:blizzard)]

This isn't a bug.

Comment 6

[timeless]

*** Bug 82855 has been marked as a duplicate of this bug. ***

Comment 7

[timeless]

vrfy blizzard doesn't consider this a bug.

Comment 8

[Christopher Blizzard (:blizzard)]

*** Bug 85829 has been marked as a duplicate of this bug. ***

Comment 9

[R.K.Aa.]

*** Bug 99481 has been marked as a duplicate of this bug. ***

Comment 10

[cls]

*** Bug 99810 has been marked as a duplicate of this bug. ***

Comment 11

[Christopher Blizzard (:blizzard)]

OK, I've gotten enough requests for this.  I'm going to fix it.

Comment 12

[Christopher Blizzard (:blizzard)]

Attachment: patch

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 49629 [details] [diff] [review]
patch

I love it.  sr=shaver

Comment 14

[Roland Mainz]

The idea of using the UID is not safe in all environments... $LOGNAME would be
better.
Think about the case that multiple users are mapped to one UID (which is
_explicitly_ allowed in unix) or nameservies like NIS+ or the DCE stuff etc.
etc.

Comment 15

[Christopher Blizzard (:blizzard)]

Well, you could make the argument that you might have the same username with
different UIDs as well.

This will cover 99% of cases.

Comment 16

[Roland Mainz]

The patch will fail to function in large NIS+ and DCE environments... that's my
point... where's the problem to use $LOGNAME instead of the UID ?

Comment 17

[Christopher Blizzard (:blizzard)]

How portable is LOGNAME?

Comment 18

[Roland Mainz]

As far as I can remember the user2netname() call may be used in such
environments to obtain a {cross-platform,cross-domain}-unique user id.
-- snip --
int user2netname(char  name[MAXNETNAMELEN+1],  const  uid_t  uid,
          Convert  from  a  domain-specific  username  to an
          operating system independent netname. Returns 1 if
          it  succeeds,  and  0  if  it  fails.  Inverse  of
          netname2user().
-- snip --

But $LOGNAME is far easier and cover 99.999% of all cases... I am sure that the
case that "two different people having the name $LOGNAME in two different
domains will share the same display" is very very rare.

Comment 19

[Roland Mainz]

> How portable is LOGNAME?

Well... I never saw a Unix/Linux machine which does not set it at login time. At
least Solaris, Linux, AIX and CrayOS set it. I cannot confirm it for IRIX/HP-UX
(I do not have access to such OSes yet) ...

Comment 20

[Christopher Blizzard (:blizzard)]

Well, you could make that same argument about UID.

Comment 21

[Roland Mainz]

> Well, you could make that same argument about UID

Even Linux has this rpc.ugid uid/gid<-->uid/gid mapper daemon which does such
uid<-->uid translations. 
Using $LOGNAME would be resitent against such a stuff - and catches even very
common NIS+/DCE cases.

Comment 22

[Andrew Taylor]

What about nsUserInfo::GetUsername from xpfe/appshell/src?  Shouldn't we get the
user name from there?

Comment 23

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I'm not sure what the problem is that we're trying to solve with $LOGNAME.  I
don't think that UID portability across machines is really the goal -- if I'm
starting mozilla against Chris's display, and we have the same UID or LOGNAME, I
would still really want a new instance to pop up, and not have it "cleverly"
open a window of Chris' running Mozilla.

So let's do UID+hostname or something else that will share where it's meaningful
(same UID on same system), and fault to a new process where it's not (different
UID or different system).  The alternative is using things like the nfs UID
mapping daemons, and nobody wants that.
Do we have access to a meaningful hostname?  IP address?

Comment 24

[Christopher Blizzard (:blizzard)]

I like the idea of (uid)@(hostname).  On unix it's just gethostname() and that's
pretty damn portable.

Comment 25

[Roland Mainz]

And what about the case that one person is logged into two machines using the
same account (identified via $LOGNAME) and using the same Xserver ? Why do we
need remote X11 when it does not work correctly anymore that way ?

Comment 26

[Christopher Blizzard (:blizzard)]

Attachment: patch that uses LOGNAME

Comment 27

[Christopher Blizzard (:blizzard)]

After thinking about it I think that gisburn is right on both counts.  This is a
patch that just uses LOGNAME and doesn't include hostname information.

Comment 28

[Roland Mainz]

Minor detail (for the reporter):
% su - myuser # is the right way

A plain
% su myuser # does not touch most ENV vars (incl. $LOGNAME).

blizzard's patch is OK; this minor detail of "su" is wanted... :-)

Comment 29

[Alec Flett]

seems reasonable.. sr=alecf

Comment 30

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 49643 [details] [diff] [review]
patch that uses LOGNAME

Yeah, this is better.  Thanks, gisburn, for setting us straight.
sr=shaver

Comment 31

[Christopher Blizzard (:blizzard)]

Checked in.

Comment 32

[Ilpo Nyyssönen]

I log from work to my home machine where I have differently named user and I
would like to be able to open urls from there. With these patches this does not
work. 

As a workaround I can set the LOGNAME for the mozilla -remote, but I would need
to do that in more than one place and I am not sure that I am able to do it in
all the places I want.

Comment 33

[timeless]

this is fixed, if you want some other behavior please file a new bug.

but please think about your request before filing it. does it make sense for a 
coworker to send my web browser to a random url as my boss walks by? (or my 
peer as my prof or g/f or the dean)