Closed Bug 51240 Opened 24 years ago Closed 19 years ago

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


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



(Not tracked)



(Reporter: ralston, Assigned: mcafee)



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

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.
Ever confirmed: true
James actually there are other problems also.  See bug 41057.
Blocks: 41057
Jay, Can you investigate this ?
Assignee: namachi → jpatel
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. 
Assignee: jpatel → warren
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.
Assignee: warren → janc
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.
would a symlink from the writeable directory to the talkback binary(ies) be 
sufficient? (or would it notice?)
Blocks: 116669
-> mcafee
Assignee: janc → mcafee
better/shorter summary
Summary: talkback requires write access to install directory → /opt install: talkback requires +w access for install dir
*** Bug 134903 has been marked as a duplicate of this bug. ***
this has been fixed since 0.9.6
Closed: 19 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.