Closed Bug 300967 Opened 19 years ago Closed 13 years ago

Global Extensions Are not Updated Properly

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bugs, Unassigned)

References

Details

Extensions installed into:

app-global
winreg-app-global
winreg-app-profile

etc. 

cannot be updated using the update process because the update procedure does the
download and installation using XPInstall's "initManagerFromChrome" method which
causes the Extension Manager to be called back via installItemFromFile, passing
"app-profile" every time - so all updates are essentially clones of the
extension, in the user's profile directory. 

There are arguments you could possibly make saying that this is not a bug,
arguments that you could make saying that this is too difficult to fix or not
worth fixing. I don't think this is a priority but wanted to get the issue on file.
Note that winreg always returns false for canAccess so update is never enabled
in the ui for a winreg item or for that matter any other item where canAccess
returns false. If no items were selected to update the code would then try to
update all items and this would bypass the canAccess check. The patch that
landed from bug 299887 changed this behavior so that it no longer tries to
update items where canAccess would have returned false. The other cases where an
item is not checked for an update are:
opType == OP_NEEDS_INSTALL
opType == OP_NEEDS_UNINSTALL
opType == OP_NEEDS_UPGRADE
appManaged == "true"
extension's update.enabled pref value == false
This WFM now, I think (at least we do not try to update them, which is the desired behavior).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Currently we only try to update extensions we can update (e.g. update is not disabled for the extension, we have write access, etc.). If we can update a global extension it will end up with a new install in the profile's extensions dir so, unless this has changed recently which I'm quite sure it hasn't this is still a problem... it is just less noticeable now that we do the right thing in regards to only updating items we can update. reopening
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 318728 has been marked as a duplicate of this bug. ***
*** Bug 333314 has been marked as a duplicate of this bug. ***
On MS Windows terminal server installed global extensions. Updating process updates extensions only in user profile...
Note: perhaps we can request elevated privileges for non-admin users... Vista's behavior will have to be figured out as well.
(In reply to comment #7)
> Note: perhaps we can request elevated privileges for non-admin users... Vista's
> behavior will have to be figured out as well.

Even if the user who's processing the update is the GOD of the computer (ie Admin with all permissions), globally installed extensions updates ends up to become user-level extension. Worse, globally installed extensions aren't uninstalled at all.
(In reply to comment #8)
Correct and the behavior of this bug is already understood.

I'm using the CCK extension to customize the Firefox installation within my company. Therefor I specify different policies e.g. proxy settings, download options, and others which should NOT be changed by users working on the computers. I can prevent this by installing the created extension as a global extension. Users don't have write access within the application folder and aren't able to modify my settings. But this will break after my extension gets an update. The new version is installed inside the profile folder where users can modify all parts of it. It will open a security hole. Especially computers in public areas will be mainly affected if the admin doesn't immediately install the update to the application folder.

The CKK extension is just an example to show what happens when installing the update to the profile folder. IMO a normal user should not be able to update a globally installed extension. But if he has write access to the application folder and the update is installed there it should be fine.

I think we should update the severity flag. 
Why are you issuing an update to the extension if you know that it has this effect? Can't you just stop doing that? Changing Firefox to ignore your updates would have the same effect.
In reply to comment #11:
OK, I've raised the severity and priority level.

In reply to comment #12:
Gavin, Henrik was talking about the situation in a multi-user system, eg WinSvr2003.  But a normal XP which is used by several users using several accounts also has this problem.
Severity: normal → major
Priority: -- → P1
Please don't play around with the flags. I would have set it on my own. But I ask to get feedback first.

Gavin, you are right. I could remove the update.xml on the server side. But IMO this is only a workaround and doesn't solve the existing issue.
Severity: major → normal
Priority: P1 → --
Version: unspecified → Trunk
I'm interested to know what update.xml you're talking about.

Mozilla.org really lacks an admin guide for Firefox.
(In reply to comment #14)
> Gavin, you are right. I could remove the update.xml on the server side. But IMO
> this is only a workaround and doesn't solve the existing issue.

The problem is that I'm not sure what you would have us do differently. In your case, we can't update the global installation properly because the user doesn't have write access to the program directory. The only other option is to ignore the update and not install it, and as I explained on IRC I don't think that's much better.
Global extensions are maintained by an administrator for e.g. a huge amount of computers. Shouldn't they be aware themself when updates are available and need a manually update? Isn't it the aim to have an extension which isn't modifiable by a normal user and by the way exists within each local profile? If not why we support global extensions?
But why shouldn't a global extension update itself in the system directory if it has write access?

It certainly shouldn't update itself into the user profile directory.
(In reply to comment #19)
> But why shouldn't a global extension update itself in the system directory if
> it has write access? It certainly shouldn't update itself into the user profile directory.

If the user has write access it definitely should update itself. That's correct and I haven't said anything other. I only talked about a normal user, who won't normally have write access to the application directory.
(In reply to comment #19)
> It certainly shouldn't update itself into the user profile directory.

So you're saying we should just ignore updates to global extensions if we can't write to their install location? That sounds dangerous... why would people be pushing updates to extensions in such controlled environments?
(In reply to comment #21)
> (In reply to comment #19)
> > It certainly shouldn't update itself into the user profile directory.
> 
> So you're saying we should just ignore updates to global extensions if we can't
> write to their install location? That sounds dangerous... why would people be
> pushing updates to extensions in such controlled environments?
> 

I'm not sure what the "right thing" is, but what we are doing now doesn't work. If I have a global extension that I have hidden or prevent the user from disabling, if it gets updated, it is now available to be hidden or disabled or uninstalled. I understand that it probably should be managed better by the distributor of the extension, but that's a separate issue here.

How do updates to Firefox work in an environment when we don't have write access to the app directory?

(In reply to comment #22)
> How do updates to Firefox work in an environment when we don't have write
> access to the app directory?

With our normal installers it's not possible for users without write access. Someone with sufficient rights have to run the update locally or via remote session. Firefox doesn't get updated to another location. If we will have official MSI installers updates using group policies will be possible AFAIR. But meanwhile it's also by hand. So what's more dangerous. Missing updates of Firefox or extensions?
If the user has write access to the app folder, he may get an update notification in SeaMonkey-trunk for ChatZilla or Venkman, which IIUC is due to this issue; and if he accepts it, the extension upgrade will be installed in his profile, overriding the app-global version (see e.g. http://wiki.mozilla.org/ChatZilla:Suiterunner#appManaged ). This is not necessarily a bug (though why not install an update in the profile even if the app-global older version cannot be overwritten?); however I would feel better if, in such cases, the update warning included a message explaining that the upgrade will override the existing version without removing it. Also (but IIUC this is a different issue, worthy of a separate bug), when the upgraded version is installed globally by upgrading the app (e.g., by installing the next nightly), the extension-update popup (or something) ought to show up at the next startup, with an option to uninstall the (now duplicate or even obsolete) version in the profile.
In reply to comment #24 - Filed bug 413153
Product: Firefox → Toolkit
Isn't the real problem that the current model actually allows unprivileged users to override the configuration maintained by the privileged user?  This is a rather serious configuration security breach, I would think.

So what if fixing this would prevent people without admin privileges from updating extensions?  That's the point - they're not intended to - that's why it's in the administrator's area!! If they don't have sufficient privileges to update, politely tell them so ("I'm sorry, Dave. I can't do that.") and ask them to contact their administrator.  Even WinDoze does that.

Less serious, but problematic in other ways, is that even an administrator cannot update the global extension within the GUI (even though the GUI has just informed him of the available update), and is forced to use manual or command line methods.

The better solution IMO is to update extensions only where they actually reside.  If the user does not have sufficient privilege to do so, merely decline and instruct - avoiding entirely the situation described in comment 24, and thereby obviating bug 413153, except that a profile extension duplicating a global extension should be silently uninstalled, as it should never have been installed in the first place and may have been created manually.

I confess I'm a newb here (but been a Unix admin 25+ years), so be gentle and constructive if I have violated some unspoken protocol.
The discussion on this bug report to date generally (but not entirely) ignores my situation.  I am the only user of a non-networked PC.  I only use the PC as Administrator.  I can write to any directory.  I am quite sure that I am not the only user with such a configuration.  

I have four distinct browser profiles.  When I install an extension, I want it to be global and not per-profile if the extension itself supports global installation.  

Currently, I'm a SeaMonkey 1.1.x user.  Thus, "global installation" means that five of my six extensions are installed in the SeaMonkey root.  The sixth extension does not support root installation.  

With SeaMonkey 2.x using the latest Add-Ons Manager, I understand that I can install those extensions in some other global directory.  Or can I?  The prior comments seem to indicate that my extensions might instead be installed only in a profile, requiring me to install each four times when there is an update.  Please clarify.  

See bug #432656.
We're not going to support automatically updating extensions in anywhere other than the profile.
Status: REOPENED → RESOLVED
Closed: 19 years ago13 years ago
Resolution: --- → WONTFIX
My globally installed got automatically updated globally via FF update from 4.0.1 to 5.0, that's fine. But will they be again become updated from e.g. 5.0 to 5.0.1.?
Now I have a few incompatible add-ons, which become automatically disabled. If they would become compatible some day, I can't have them updated and enabled in time, if the are installed globally. That's more than a pity.
They will reside there for almost ever :-(

OK, I can make the incompatibles enabled via "Addon Compatiblity Reporter", but that's a security risk.
(In reply to Dave Townsend (:Mossop) from comment #30)
> We're not going to support automatically updating extensions in anywhere
> other than the profile.

This statement appears wrong!
I updated FF from 10.0.0 to 10.0.1.
After restart I was informed, that the 'Minimap Addon' is no more compatible.
(Version 0.3.13 was installed globally)
I acknowledged for search for compatible updates.
After, version 0.3.17 was automatically installed properly in global extensions folder.
As we can see, global extensions update (1) is possible and (2) happens under the condition, that add-on became incompatible.
So please make global extensions up-datable, automatically and/or via Add-ons Manager, even if they are just outdated.
Blocks: 726567

Also depends on or is related to bug 432656.

You need to log in before you can comment on or make changes to this bug.