333012 - Locked extensions should not be able to be disabled

Status: VERIFIED INVALID

(Toolkit :: Add-ons Manager, defect)

Description

[Mike Kaply [:mkaply]]

Currently there is a mechanism to lock a system extension so it can not be uninstalled.

However, it can still be disabled.

If an extension is locked, it should not be able to be disable either.

Comment 1

[Mike Kaply [:mkaply]]

Attachment: Fix for problem

basically just add the check that we use for uninstall to disable.

Comment 2

[Benjamin Smedberg]

locked means that the extension is updated with the application, it does not mean that the user shouldn't be able to disable it.

Comment 3

[Robert Strong (they/them - no direct email)]

Actually, appManaged means an extension is updated with the application. Locked has been used for preventing uninstall but the full behavior / use cases for locked has not been afaik thought out or implemented. Ben may be able to shed some light on this.

Michael, is this something you need and if so, can you provide the use case? I'd like to have at least some of the use cases for locked defined before it is implemented further.

Comment 4

[Mike Kaply [:mkaply]]

Use case is the client customization kit (http://www.mozilla.org/projects/cck/firefox)

For corporate browser deployments it would be useful to have extensions installed that can be updated but cannot be uninstalled/disabled.

The alternative here is to use hidden which works, but then the extension can't be updated.

Comment 5

[Robert Strong (they/them - no direct email)]

I wonder if the use case of having an extension that can't be uninstalled and can be enabled / disabled isn't also valid? For example, an extension installed in the application's extensions directory, all users have write access, and the sysadmin doesn't want the extension uninstalled but wants to give the users the ability to disable / enable the extension.

Comment 6

[Mike Kaply [:mkaply]]

I definitely think this is a use case as well. There might be cases where you want to disable an extension to see if it is affecting browser behavior for instance.

Comment 7

[Robert Strong (they/them - no direct email)]

I ran this by Ben and his comments were in support of preventing disable for locked extensions. It can still be disabled in safe mode for testing whether it is affecting the app's behavior. I'd like to think this through a bit more but my initial thought is it is appropriate to do this. I also want to verify that the safe guards are in place so this doesn't apply to extensions installed into the profile. One edgecase this will create is that the user could install the same extension into their profile which will take precedence over the one installed into the app directory and they will then be able to disable the extension.

For now, I think preventing uninstalls is handled well enough by the fact that we don't allow uninstalls of extensions that are installed into a location that we don't have write access to.

Benjamin, do you have any concerns regarding this?

Comment 8

[Mike Kaply [:mkaply]]

Incidentally, both the hidden and locked options work for profile installed preferences.

Comment 9

[Mike Kaply [:mkaply]]

Incidentally, both the hidden and locked options work for profile installed extensions.

Comment 10

[Robert Strong (they/them - no direct email)]

I haven't tested it but it shouldn't be added when using the normal install methods except with locations that are considered restricted
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#7093

Comment 11

[Mike Kaply [:mkaply]]

true, but any extension is free to add hidden and locked to it's own entry in the extension RDF by explicitly manipulating the data source.

I tried this and it worked.

Comment 12

[Robert Strong (they/them - no direct email)]

Yes, as well as do many other things. Also, the file can be hand edited to make this happen.

I could make the datasource always return false for addons installed into the profile directory but I see little point in doing so. The same extension that could modify the datasource could also install itself into a restricted location where these values are accepted... or for that matter it could do any number of the other things an extension can do to a system after it is installed.

Comment 13

[Varun]

In support of Comment #5; if this bug is going to be resolved, would there be a way I could let users chose if they want to disable enable extensions in the global app directory. I suggest they should be able to enable and disable extensions but not uninstall them in a corp environment. If they disable them, it does not affect other users, but if they uninstall them, it affects all users on that pc. 

regards
shivanand sharma
Firefox Corporate Deployment Guide
http://varun21.googlepages.com/blog.html

Comment 14

[Mike Kaply [:mkaply]]

That's fair. Basically if a company doesn't want an extension uninstalled or disabled, they can hide it.

Comment 15

[Robert Strong (they/them - no direct email)]

The trouble with that approach is if the extension has options then the options won't be accessible.  It is possible to make it so they can't be uninstalled, can be enabled / disabled, and have options available by making the app extensions directory read only for the users of the system.

Comment 16

[Robert Strong (they/them - no direct email)]

I'm fine with doing this but the next bug that is going to be filed is to provide user feedback as to why they can't uninstall. If we are going to prevent disabling of locked extensions the new ui indication should be done preferably at the same time. Would you be willing to do this as well in this patch?

Comment 17

[Mike Kaply [:mkaply]]

The bummer part here is that we typically replace the description of the extension with the status.

so just having a "This extension has been locked by an administrator" as the status, means we lose the description..,

Comment 18

[Robert Strong (they/them - no direct email)]

Not on the trunk and hopefully not on the branch soon either... I fixed that with the ui rewrite (see bug 329045). I'd suggest displaying the same badge as used when an add-on is incompatible, blocklisted, etc. and display the message as a new status message as is done for incompatible, blocklisted, etc. 

Comment 19

[Robert Strong (they/them - no direct email)]

Comment on attachment 217442 [details] [diff] [review]
Fix for problem

I don't want to take this without ui changes since a bug report to provide that would likely follow. I think this is the correct thing to do and a patch that includes the ui changes would be appreciated.

Comment 20

[Dave Townsend [:mossop]]

We no longer support locked extensions

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #20)
> We no longer support locked extensions

Michael, would that raise any problem for your extension?

Comment 22

[Mike Kaply [:mkaply]]

I was biting my tongue.

Removing the ability to lock extensions is removing an important enterprise feature.

But as long as we have the ability to overlay the add-on manager and manipulate the add-on list there, I'll be able to work around this.

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dave, so extensions can disable the buttons for their own entry?

Comment 24

[Dave Townsend [:mossop]]

(In reply to comment #23)
> Dave, so extensions can disable the buttons for their own entry?

Sure, extensions can do whatever they like, however locked extensions are probably better replaced with distribution bundles which don't show up in the add-ons manager at all and so cannot be disabled.

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks Dave. Given that information I verify the bug. Michael, whenever you have problems with CCK please report back.