201966 - Make extensions usable - extensions should be installed in profile dir with user permissions per default.

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Daniel Küstner]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

Since bug 12561 is fixed, extensions creators can decide to provide installation
to profile directory. But default installation still goes to the mozilla tree -
which causes no extension to be installed into profile dir at the moment -
except for themes and might be language packs (which I didn't try).

As of the new roadmap extensions will become much more important than they are
now, the mozilla suite will get hardly usable on Unix. Installing extensions
with root permissions is bad, because (the following arguments are taken from an
article in n.p.m.seamonkey):

=============

- Extensions in your profile dir do not alter the Mozilla executable at all.

- Starting complex applications like mozilla as root is a security risk.
Starting it with extensions of untrusted origin is bad. And you have to start
mozilla in order to install extensions.

- Plugins and themes can be installed on a per-user base. Why can't extensions?

- On multi user systems (like companies and universities) the admin has to care
on extension installation. This causes much work for him/her.

- It is even possible today to install extensions in your profile dir, if the
creator of that extension makes it possible. What I am asking for is to make
this behaviour the default behaviour, because most extension creators don't care
for permissions on unix systems. 

=============

I don't know, how permissions are handled with Windows XP and MacOS. If there
are the same issues, OS should be set to ALL and summary should be adjusted.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Boris 'pi' Piwinger]

ACK. Without this addons are not usable at all. Might even be critical.

pi

Comment 2

[Boris Zbarsky [:bzbarsky]]

ccing some people who would actually be implementing this, as well as interested
parties...  Agreed that this is nearly a must-have for a decent extension
mechanism on Linux.

Comment 3

[James Graham]

FWIW, I heard Multizilla tried installing to the profile directory for some
builds early in 1.4, and people disliked it (see
http://www.mozillazine.org/forums/viewtopic.php?t=8678). If these objections to
profile only install are valid (I have no I idea what the objections are), it
might be best if Mozilla provided an install dialog along the lines of:

Installing extension blah.
Do you wish to make this extension avaliable in the current profile only or in
all profiles on your system?
[Install in this profile]  [Install in all profiles]

rather than leaving the extension author to provide the options. Obviously if
Mozilla could determine that the mozilla tree chrome directory was not
writeable, it could just go ahead and install to the profile directory.

In any case I agree that installing to profile by default is better, regardless
of whether the system enforces permissions on the mozilla directory or not -
therefore the OS should be all.

Comment 4

[Boris 'pi' Piwinger]

I agree with James. Checking permissions is essential. Right now Mozilla even
says, that installation was successful when it failed badly.

Further, I don't think, that an addon should decide or even suggest where it
likes to be installed. So the choice James suggested is a good one, if available.

pi

Comment 5

[Robert Kaiser]

If you want to install globally, and Mozilla detects that doesn't have write
permission there, I believe it should ask for the root password and call an
install process (and only that install process) as root, doing the global
install there.
Users that fear it's bad to let Mozilla call anything as root, might just cancel
the dialog when it asks for the password, stating what it needs it for and that
this might be dangerous.

Comment 6

[Boris Zbarsky [:bzbarsky]]

There is the second question here.  How does the sysadmin install extensions
without launching Mozilla as root?

Comment 7

[Daniel Küstner]

KaiRo: This bug is not on global install. It is the request to make local
install the default behaviour, or at least to let the user (not the extension
maker) decide. If global install is default behaviour and there is no (easy)
possibility for the user to change that, extensions become unusable for many
users who want to use extensions. The main reasons are

a) security awareness
b) no knowledge of the root password (multi user systems - companies and
universities)
c) easy upgrade of mozilla without installing all extensions new.

While c) is not very important as many extensions may be broken with new
versions, a) and b) make extensions unusable on many systems. And, as stated
above, there is no reason why plugins can be user-installable but estensions can
not.

IMHO is your request for a root password question another bug, enhancement in
this case.

Comment 8

[Simon Paquet [:sipaq]]

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

Comment 9

[William Night]

Some pluggins, when installed as root, use permission 600 for all of their files
which means that user's can't read the pluggin. When mozilla 1.5 running as a
user encounters one of these pluggins it silently hangs when trying to load,
without popping up any dialog box. When run again (as a user would if they
didn't know to look for the lock file) it brings up the profile selector and
tells the user that the profile is already in use but doesn't offer any explanation.

Installing the pluggins in the users directory would fix this, but Mozilla
should also fail gracefully (or at least with a visible error message) when it
encounters chrome it can't read.

Comment 10

[Daniel Küstner]

William: This bug is not on plugins. I'm not sure if you chose the wrong term
and meant extensions, but even in this case it would be good to open a new bug.

Comment 11

[Daniel Küstner]

Changing summary, as this applies also to at least Mac OS X

Comment 12

[Daniel Küstner]

The according firefox bug is bug 204049.

Comment 13

[Philip Chee]

FIXED due to moving to the toolkit addons manager.