Closed Bug 105679 Opened 23 years ago Closed 23 years ago

Must surf as root for XPinstall under Linux

Categories

(SeaMonkey :: Installer, defect)

x86
Linux
defect
Not set
minor

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: lemire, Assigned: slogan)

References

()

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
BuildID:    2001101201

Say I want to install multizilla under Linux. I visit multizilla.mozdev.org as a
user (of course, since I don't surf as root!). I then click on the proper link
having "software installation" enabled.

It will then download the package and say *nothing*.

In effect, the package never gets installed and I'm not even sure it was ever
saved to disk.



Reproducible: Always
Steps to Reproduce:
1. Install Sun's JVM under Linux 
   (rpm -ivh j2sdk-1_4_0-beta2-linux-i386.rpm for example)

2. You can verify that a mozilla-compatible plugin is available under
/usr/java/j2sdk1.4.0/jre/plugin/i386

1. Install mozilla under Linux.

2. Visit a page like http://multizilla.mozdev.org/installation.html where you
can install a component. (Surf as a user, not as root!)

3. Click on the proper link, wait till the download is done.








Actual Results:  You receive no error message. The package was never installed.


Expected Results:  The package should get installed if only in user space (under
$HOME/.mozilla). 

At the very least, a proper error message should pop up saying that you can't
install components as a user (please give the warning *before* the download!).

I don't see why you expect people to surf as root??? That's not a good practice.

You could allow root to disable software installation for all users.

Workaround: quit mozilla, log on as root, visit the web page, install the
package, quit mozilla, log on as user and use package.

In effect, this forces you to surf as root for some time. I don't see how it can
be considered a good thing!
Status: UNCONFIRMED → NEW
Ever confirmed: true
dupl bug 41057?

According to dveditz@netscape.com in that bug, it's the job of the XPInstall JS
to put files into the Profile directory instead of the Chrome directory. If
that's true, then the bug is actually in the XPI file, not Mozilla.
There are more specific bugs of which this is a duplicate, I just haven't dug
them out yet. Mostly this is a script problem in the particular scripts being
installed (thus INVALID), though it could perhaps be considered a DUPLICATE of
the feature request for an error alert at the end of the install. The "install
java" steps confuse me, I'm not sure how they're relevant here. Java is a
special case in that it probably doesn't work if not installed in the correct
place, and in order to install you will have to have write privileges into the
Mozilla plugins directory (please, not "root" -- you should have a "bin" user
with privileges to write to the system applications area).

I'm picking the INVALID (bad script) part because I'm too swamped to hunt down
the relevant duplicates. Bug 41057 is too general though.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
duplicate of bug 29741 ?
Verified invalid
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Component: Installer: XPI Packages → Installer
QA Contact: ktrina → general
You need to log in before you can comment on or make changes to this bug.