51240 - /opt install: talkback requires +w access for install dir

Status: RESOLVED FIXED

(Core Graveyard :: Talkback Client, defect, P3)

Description

[James Ralston]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m17) Gecko/20000807
BuildID:

I am running Mozilla on Red Hat Linux 6.2 (i386).  I have packaged Mozilla as an
RPM; it installs itself into /opt/mozilla, which is recursively owned by root.
My RPM provides a front-end launcher, /usr/bin/mozilla, that changes the current
working directory to /opt/mozilla and runs ./mozilla.

I discovered that when Mozilla crashed, the talkback feature was not invoked.
After some experimentation, I figured out that talkback would work if I
recursively chown'ed /opt/mozilla directory to myself.  After it ran, I ran "rpm
--verify mozilla" and discovered that multiple files and/or directories had
changed under /opt/mozilla.

This is bogus.  Not talkback, nor any other part of Mozilla should depend on the
installation directory being writable by the person running Mozilla.  If I can't
package Mozilla as an RPM, and put it in a reasonable place (e.g., /opt/mozilla)
so that everyone on my system can run it--in other words, if EVERY SINGLE PERSON
who wants to use Mozilla has to have a 34MB tarball in their home
directory--then I will simply not use Mozilla.

The changes to Mozilla to make it behave like "real" software--that is, to
assume that its installation directory is off-limits, and for it to use
~/.mozilla for all dynamic data--can't be that hard.  Please make these changes.


Reproducible: Always
Steps to Reproduce:
1. Install mozilla as a system package (e.g.; in /opt/mozilla, where
/opt/mozilla and everything beneath it is owned by root.

2.  Change directories to /opt/mozilla and run ./mozilla

3.  Do something to cause mozilla to crash.


Actual Results:  Talkback will not be invoked.


Expected Results:  Talkback should have been invoked.

Comment 1

[David Krause]

James actually there are other problems also.  See bug 41057.

Comment 2

[Shiva Thirumazhusai]

Jay, Can you investigate this ?

Comment 3

[Jay Patel [:jay]]

I don't know why this is assigned to me, so assigning it to warren, the owner of 
bug 41057.  I'm also not a linux person, so I don't know how much I will be able 
to play around with the installation in attempting to reproduce...but I will try 
when I have some time. 

Comment 4

[Daniel Veditz [:dveditz]]

This shouldn't be warren. Picking janc because she's the owner of 60099 which is
essentially the same thing, although this one is unix and not win32. It's
probably useful to leave both reports open because there's no quarantee both
versions of talkback would get upgraded at the same time, and they'd have to be
tested separately in any case.

Comment 5

[Daniel Veditz [:dveditz]]

See hack I discuss in bug 60099 (the windows version of this bug). It's 
possible a similar hack would work on unix, though it requires copying the 
talkback binaries themselves into a user-writable directory.

Comment 6

[timeless]

would a symlink from the writeable directory to the talkback binary(ies) be 
sufficient? (or would it notice?)

Comment 7

[Shiva Thirumazhusai]

-> mcafee

Comment 8

[Chris McAfee]

better/shorter summary

Comment 9

[Chris McAfee]

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

Comment 10

[Andrew Schultz]

this has been fixed since 0.9.6