Firefox 3.6 does not honour lockPref

Created an attachment (id=326061)
patch

Obviously, neither the debian changelog nor the fprintf should be in the patch. The first patch doesn't exist. You haven't seen it. The only patch existing is this one.

Because I apparently inherited ownership of this code by default, I'm going to need some more summary here:

* what is the motivation for this change?
* where did lockPref use to work? In what new cases are we making it work?
* I'm going to need tests. I think writing an xpcshell test for this shouldn't be too hard.

(From update of attachment 326061)
canceling review request until questions are answered

(In reply to comment #2)
> Because I apparently inherited ownership of this code by default, I'm going to
> need some more summary here:
>
> * what is the motivation for this change?
> * where did lockPref use to work? In what new cases are we making it work?

lockPref is an exclusive feature of the autoconfig stuff right now. Autoconfig uses a single file, located in the application directory, and which name is given by the general.config.filename preference, with pseudo security featured by a general.config.obscure_value preference.

Autoconfig also allows to use javascript constructs, contrary to standard pref files that are limited to pref() and user_pref().

The problem we had in debian is that we need to lock some preferences, to avoid users to harm themselves with bad preferences. app.update.enable, for instance. The first solution was to use the general.config.filename/obscure_value pair to just do that. The problem is that this file being provided by the package, it is also overwritten on any package upgrade, which means admins needing to use autoconfig just can't.

I found it a convenient way to solve this by allowing standard preferences to lock preferences.

I'm pretty sure you can find some other uses to this feature.

> * I'm going to need tests. I think writing an xpcshell test for this shouldn't
> be too hard.

Can you still review the patch without the tests ?

Frankly, to solve the specific case of Debian users trying to enable updates, I think the best course of action is to get rid of the app.update.url pref from the Debian builds: then even if the user were to turn updates on, nothing bad could happen.

I'm trying to find somebody to help walk through the twisted jungle here; this is not likely to make it for FF3.1 because it touches something close to PAC, which is some of our most fragile code.

This has nothing to do with app.update.url, but with admins wanting to lock some prefs to their users without fidling with general.config.filename.

Which may be a worthwhile use case, but I'm pretty sure we don't want extensions to be able to lock preferences (for example), and it's not clear to me that we distinguish between admins and extensions very well.

Actually, AFAIK, an extension can already lock preferences...

(From update of attachment 326061)
At least extensions should not be allowed to set locked prefs, so r-. I'm not sure what the right design is.

As I said, extensions can already lock preferences...

(From update of attachment 326061)
Re-requesting review due to glandium's overlooked comment.

How can an extension lock preferences?

Created an attachment (id=347810)
extension locking a pref

This is one way i was thinking of for an extension to lock a preference. There are, I guess, many others.

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

(From update of attachment 326061)
ok, yes, extensions can do anything. I don't think we want them doing this, and this will be an attractive nuisance.

The point is, extensions already can lock prefs, so why not allow this patch, which doesn't change that, and file another bug to prevent extensions from locking prefs ?

(From update of attachment 326061)
Re-requesting review per comment #16

Comment on attachment 326061
patch

I cannot review this without spending boatloads of time understanding the use cases and code, which I don't think is worth my time at this point. Sorry :-(

Just voted for this bug. We are locking certain prefs in the default installation (for example browser and extension updates are done via packages, so we diable eg "app.update.enabled").

Debian is shipping a patch in their packages, Ubuntu isn't (see https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/623844).

Created attachment 572068
Allow .js preference files to set locked prefs with lockPref()

Refreshed after the PRBool/bool change.

Now, as bsmedberg won't review it, and dwitte is essentially not around anymore, who can review this?

Created attachment 576542
Allow .js preference files to set locked prefs with lockPref()

Sorry for the noise, just testing "hg bzexport". I'm still interested to know who could review this, though.

This is a fly by night review.

I don't think it should be "lockPref" like autoconfig. With autoconfig, it's a function call.

With the default pref files, you're specifying a preference.

so:

locked_pref("foo", "bar")

makes more sense it that context (the same as user_pref)

Looking through the code, it looks like you've assumed that if a pref is locked, it becomes a default as well, is that correct?

The code looks good to me, but I'm not the right person to do this.

I think this is a good solution to the problem you are seeing and makes it a lot easier for enterprises to lock prefs, so this would be a good thing to have.

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

(In reply to Benjamin Smedberg [:bsmedberg] (Away 24-25 October) from comment #18)
> Comment on attachment 326061
> patch
>
> I cannot review this without spending boatloads of time understanding the
> use cases and code, which I don't think is worth my time at this point.
> Sorry :-(

In that case, can you suggest someone that could review it?

No, at this point I don't think there is anyone who can own and review this.

seems like there is some interest in this bug over in

 https://bugzilla.mozilla.org/show_bug.cgi?id=984012#c15
 https://bugzilla.mozilla.org/show_bug.cgi?id=984012#c17

to help protect international users from getting phished into changing the pref named security.turn_off_all_security_so_that_viruses_can_take_over_this_computer

and not necessarily understanding the ramifications of that action if they don't understand English.

Created attachment 8613433
Allow .js preference files to set locked prefs with lockPref()

Refreshed after bug 1098343. Benjamin, would you like to review this, this time, considering comment 26?

You didn't address my comments.

I really don't want it being called lockPref. That will confuse it with the autoconfig "lockPref" function.

There is already enough confusion with pref()

(In reply to Mike Kaply [:mkaply] from comment #28)
> I really don't want it being called lockPref. That will confuse it with the
> autoconfig "lockPref" function.

What is confusing? It's the same syntax. The only difference aiui, is the execution environment, which means autoconf can do more javascript-y things, which, as you point out, is already a source of confusion. I'd argue that having two different names is what would be confusing.

It's not the same syntax, that's my point.

pref() in a prefs.js file is NOT the same as pref() in an AutoConfig.js file.

pref() in prefs.js sets the default pref, defaultPref() in an Autoconfig sets a default pref.

user_pref() in prefs.js sets a user pref, pref() in an AutoConfig file sets a user preference.

So what you're doing is making it look like autoconfig.js and prefs.js use the same syntax, when they do not.

(In reply to Mike Kaply [:mkaply] from comment #30)
> It's not the same syntax, that's my point.

I tend to agree here. I think this could be a useful patch (I'd use it instead of doing autoconfig stuff) but it's kind of silly to be hung up on naming...

I do think that "lockPref" sticks out relative to the calls for "default_pref", and "sticky_pref". I'm a +1 for calling it "locked_pref".

The syntax is a triviality of the patch. The core problem here is that there's no one to review the patch so that it possibly lands.

:(

Ideally, I'd like to favor this patch over the one I proposed at https://bugzilla.mozilla.org/show_bug.cgi?id=976334 - since it has been tried and tested for so long...and that just adds another use case for this: ease of locking preferences for android distributions (which aren't as straightforward when it comes to specifying the autoconfig file in the install directory)

Is it just a matter of having someone sign off on it, or were there outstanding concerns outside of the syntax? It seemed like it kind of just got dropped due to time constraints 2+ years ago, but that there now are actually some compelling use cases for it.

Can't the fact that it's been needed and used by Debian for so long be an indication of the stability and/or utility of the patch? just an appeal to *someone* to perhaps move this along...

Aside from that, :glandium - how often does this patch "break"...that is, how many times have you had to rework it because of changes in the upstream code? I ask because I actually would consider applying this patch and using it in my own distribution - even if it never lands.

From a quick glance at the history of the patch in Debian, in the past 5 years, I had to do actual but trivial code changes twice, and adapt to context changes twice (one of them having been the change from PRBool to bool)

(In reply to Mike Hommey [:glandium] (VAC: 31 Dec - 11 Jan) from comment #32)
> The syntax is a triviality of the patch. The core problem here is that
> there's no one to review the patch so that it possibly lands.

Can I help review?

Comment on attachment 8613433
Allow .js preference files to set locked prefs with lockPref()

Because this came up on the mailing list, I'll try to be explicit about the decision here. I don't think we should allow extensions to lock preferences, and we don't even have a clear description (other than this code) of what it means to "lock" a preference: whether changes to the default value are still allowed, or the user value, etc.

The code is the incidental part of this; it's the basic problem and solution space that's totally unclear.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #36)
> Because this came up on the mailing list

Which mailing list is that? (just so I can make sure I'm following the right one)

(In reply to Benjamin Smedberg [:bsmedberg] from comment #36)
> Comment on attachment 8613433
> Allow .js preference files to set locked prefs with lockPref()
>
> Because this came up on the mailing list, I'll try to be explicit about the
> decision here. I don't think we should allow extensions to lock preferences,

As mentioned in the long history of this bug, extensions can already lock preferences. See the attached xpi.

To expound on what :glandium said:

Extensions can lock preferences with:

  Components.classes["@mozilla.org/preferences-service;1"]
            .getService(Components.interfaces.nsIPrefService)
            .getBranch(null)
            .lockPref("name_of_pref");

Locking a preference doesn't affect the value, it just locks the preference to the user. Obviously any extension could unlock a preference and do what they want with that value.

Locking preferences is not for the benefit of preventing other extensions from messing with things, it's to keep users from messing with things.

Oddly, this document:

https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences

Says we already support lockPref in JS files?

(In reply to Mike Kaply [:mkaply] from comment #39)
> Oddly, this document:
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/
> A_brief_guide_to_Mozilla_preferences
>
> Says we already support lockPref in JS files?

It says: "All preferences files may call pref(), user_pref() and sticky_pref(), while the config file in addition may call lockPref()."
which is about autoconf.

(In reply to Mike Hommey (VAC: 31 Dec - 11 Jan) [:glandium] from comment #40)
> (In reply to Mike Kaply [:mkaply] from comment #39)
> > Oddly, this document:
> >
> > https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/
> > A_brief_guide_to_Mozilla_preferences
> >
> > Says we already support lockPref in JS files?
>
> It says: "All preferences files may call pref(), user_pref() and
> sticky_pref(), while the config file in addition may call lockPref()."
> which is about autoconf.

You'd think I would have noticed that. I really don't like a document that combines the two. pref behaves differently on both, user_pref doesn't work in autoconfig and sticky_pref doesn't work in autoconfig. This shouldn't reference autoconfig at all.

Comment on attachment 8613433
Allow .js preference files to set locked prefs with lockPref()

>From b8015e0754742650a4877de9ebe7d6db2671970d Mon Sep 17 00:00:00 2001
>From: Mike Hommey <email address hidden>
>Date: Sat, 21 Jun 2008 02:48:46 +0200
>Subject: [PATCH] Allow .js preference files to set locked prefs with
> lockPref()
>
>---
> modules/libpref/prefapi.cpp | 5 ++++-
> modules/libpref/prefapi.h | 3 ++-
> modules/libpref/prefread.cpp | 12 +++++++++---
> modules/libpref/prefread.h | 4 +++-
> 4 files changed, 18 insertions(+), 6 deletions(-)
>
>diff --git a/modules/libpref/prefapi.cpp b/modules/libpref/prefapi.cpp
>index e898433..081c922 100644
>--- a/modules/libpref/prefapi.cpp
>+++ b/modules/libpref/prefapi.cpp
>@@ -1002,16 +1002,19 @@ static nsresult pref_DoCallback(const char* changed_pref)
> return rv;
> }
>
> void PREF_ReaderCallback(void *closure,
> const char *pref,
> PrefValue value,
> PrefType type,
> bool isDefault,
>- bool isStickyDefault)
>+ bool isStickyDefault,
>+ bool isLocked)
> {
> uint32_t flags = isDefault ? kPrefSetDefault : kPrefForceSet;
> if (isDefault && isStickyDefault) {
> flags |= kPrefStickyDefault;
> }
> pref_HashPref(pref, value, type, flags);
>+ if (isLocked)
>+ PREF_LockPref(pref, true);
> }
>diff --git a/modules/libpref/prefapi.h b/modules/libpref/prefapi.h
>index f1e412a..24618a7 100644
>--- a/modules/libpref/prefapi.h
>+++ b/modules/libpref/prefapi.h
>@@ -181,14 +181,15 @@ nsresult PREF_UnregisterCallback( const char* domain,
> /*
> * Used by nsPrefService as the callback function of the 'pref' parser
> */
> void PREF_ReaderCallback( void *closure,
> const char *pref,
> PrefValue value,
> PrefType type,
> bool isDefault,
>- bool isStickyDefault);
>+ bool isStickyDefault,
>+ bool isLocked);
>
> #ifdef __cplusplus
> }
> #endif
> #endif
>diff --git a/modules/libpref/prefread.cpp b/modules/libpref/prefread.cpp
>index 6c4d339..16c5057 100644
>--- a/modules/libpref/prefread.cpp
>+++ b/modules/libpref/prefread.cpp
>@@ -38,16 +38,17 @@ enum {
> PREF_PARSE_UNTIL_EOL
> };
>
> #define UTF16_ESC_NUM_DIGITS 4
> #define HEX_ESC_NUM_DIGITS 2
> #define BITS_PER_HEX_DIGIT 4
>
> static const char kUserPref[] = "user_pref";
>+static const char kLockPref[] = "lockPref";
> static const char kPref[] = "pref";
> static const char kPrefSticky[] = "sticky_pref";
> static const char kTrue[] = "true";
> static const char kFalse[] = "false";
>
> /**
> * pref_GrowBuf
> *
>@@ -126,17 +127,17 @@ pref_DoCallback(PrefParseState *ps)
> break;
> case PREF_BOOL:
> value.boolVal = (ps->vb == kTrue);
> break;
> default:
> break;
> }
> (*ps->reader)(ps->closure, ps->lb, value, ps->vtype, ps->fdefault,
>- ...

Created attachment 8931547
Bug 440908 - Allow preference files to set locked prefs.

Review commit: https://reviewboard.mozilla.org/r/202672/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/202672/

Comment on attachment 8931547
Bug 440908 - Allow preference files to set locked prefs.

https://reviewboard.mozilla.org/r/202672/#review208008

As per our IRC discussion, I think this is a good feature, and the patch does a good job of implementing it. But before doing this I'd like to officially split the prefs file format in two -- one format for default prefs, and one for user prefs -- and then only support `locked_pref` in default prefs files. And I want to need to think about that for a bit, just to make sure it's a good idea.

::: modules/libpref/Preferences.cpp:238
(Diff revision 1)
> enum
> {
> kPrefSetDefault = 1,
> kPrefForceSet = 2,
> kPrefSticky = 4,
> + kPrefLocked = 8,

The patches in bug 1394578 are going to bitrot this again. Sorry :(

::: modules/libpref/Preferences.cpp:949
(Diff revision 1)
> char* mLbEnd; // line buffer end
> char* mVb; // value buffer (ptr into mLb)
> Maybe<PrefType> mVtype; // pref value type
> bool mIsDefault; // true if (default) pref
> bool mIsSticky; // true if (sticky) pref
> + bool mIsLocked; // true if (locked) pref

It would be nice to replace these three bools with a single enum that has the following alternatives: Default, StickyDefault, LockedDefault, User. That would simplify some of the code below.

::: modules/libpref/test/unit/test_lockedprefs.js:20
(Diff revision 1)
> +}
> +
> +add_test(function notChangedFromAPI() {
> + resetAndLoad(["data/testPrefLocked.js"]);
> + Assert.strictEqual(ps.getBoolPref("testPref.unlocked.bool"), true);
> + Assert.strictEqual(ps.getBoolPref("testPref.locked.bool"), false);

Keeping track of the true and false values here is tricky. If you changed it to an int you could make the "testPref.locked.int" use 100 and 101, and "testPref.unlocked.int" use 200 and 201, or something like that, and it would be a bit easier to read.

::: modules/libpref/test/unit/test_lockedprefs.js:24
(Diff revision 1)
> + Assert.strictEqual(ps.getBoolPref("testPref.unlocked.bool"), true);
> + Assert.strictEqual(ps.getBoolPref("testPref.locked.bool"), false);
> +
> + ps.setBoolPref("testPref.unlocked.bool", false);
> + Assert.ok(ps.prefHasUserValue("testPref.unlocked.bool"),
> + "should be able to set an unlocked pref");

This string comment isn't quite right, because you can set a locked pref.

::: modules/libpref/test/unit/test_lockedprefs.js:29
(Diff revision 1)
> + "should be able to set an unlocked pref");
> + Assert.strictEqual(ps.getBoolPref("testPref.unlocked.bool"), false);
> +
> + ps.setBoolPref("testPref.locked.bool", true);
> + Assert.ok(ps.prefHasUserValue("testPref.locked.bool"),
> + "somehow, the user value is still set");

This comment string is a bit weird too.

This bug seems to be stalled

Is there anything I may do to help get it advanced?

The preferences code is being heavily refactored, and this needs to wait a bit for things to settle first. That being said, I do think the ideal timing for this would be to get it into 60. Nick, what do you think?

Looking forward to see the patch landed as we use it at Fedora.

> Looking forward to see the patch landed as we use it at Fedora.

For what purpose? user.js shouldn't be used for anything mission critical at all.

@glandium

I see Comment #46 speaks of a FF 60 ESR release; but effort expended to a continuation '.js' amendments to configurations appears to conflict with the the '.json' configuration management direction outlined for 60 as well, at:

> https://wiki.mozilla.org/Firefox/EnterprisePolicies

Policies

The list of policies to support is still being defined, and is based on previous experience with what enterprises have asked in the past. Stay tuned for an official list of policies to be announced in the near term.

Some possibilities that are being discussed are:

    Disabling access to internal configuration features like about:config, about:addons, etc.
    Adding a set of bookmarks to the toolbar and the bookmarks menu
    Displaying the menu bar by default
    Disabling Telemetry
    Disabling features such as Pocket, Firefox Screenshots, Printing, Copy&Paste, etc.
    Whitelist and blocklist of domains to be allowed to be accessed
    Pre-populated permissions around cookies, storage, popups, plugins, etc.

-------

I wish a Statement of Roadmap were more clear -- I ran through the tracker bug on: EnterprisePolicies and it seems pretty far along

user.js was never intended to be an enterprise level feature for configuration of Firefox. I don't recommend using it for that.

For enterprise configuration, we have provided Autoconfig since day one, and we are working on a better solution involving JSON, GPO and possibly authors.

Our goal is to move away from the various hack solutions that folks have created in order to configure Firefox.

What specific customizations are you looking to do with Firefox? You can see the policies we are working on here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1428920

The ability to lock prefs at the .js level is not *only* for enterprise customization. Specifically, we have many "prefs" that are meant to allow e.g. per channel (release, beta, nightly) tweaks but are not meant for users to change. There are multiple such footguns that would be avoided by having firefox ship those as locked.

I was only referring to the use of user.js for enterprise. I do understand that it's worthwhile to have locking of prefs in JS file for Firefox purposes.

(In reply to Mike Hommey [:glandium] from comment #46)
> The preferences code is being heavily refactored, and this needs to wait a
> bit for things to settle first. That being said, I do think the ideal timing
> for this would be to get it into 60. Nick, what do you think?

If things go well with the prefs changes this might be possible in 60, it just depends how quickly the work goes.

Created attachment 8956309
Bug 440908 - Remove gIsAnyPrefLocked.

It optimizes Preferences::IsLocked(), but that function is called fewer than
200 times while starting the browser and opening a range of tabs.

Review commit: https://reviewboard.mozilla.org/r/225182/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/225182/

Created attachment 8956310
Bug 440908 - Add support for `sticky` and `locked` attributes to default prefs.

Sticky prefs are already specifiable with `sticky_pref`, but this is a more
general attribute mechanism. The ability to specify a locked pref in the data
file is new.

The patch also adds nsIPrefService.readDefaultPrefsFromFile, to match the
existing nsIPrefService.readUserPrefsFromFile method, and converts a number of
the existing tests to use it.

Review commit: https://reviewboard.mozilla.org/r/225184/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/225184/

Created attachment 8956311
Bug 440908 - Convert sticky prefs in default pref files to the new syntax.

Review commit: https://reviewboard.mozilla.org/r/225186/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/225186/

Comment on attachment 8956309
Bug 440908 - Remove gIsAnyPrefLocked.

https://reviewboard.mozilla.org/r/225182/#review231210

Comment on attachment 8956310
Bug 440908 - Add support for `sticky` and `locked` attributes to default prefs.

https://reviewboard.mozilla.org/r/225184/#review231212

::: modules/libpref/Preferences.cpp:3982
(Diff revision 1)
> - Preferences::GetCString(kChannelPref, updateChannelPrefValue,
> - PrefValueKind::Default);
> + Preferences::GetCString(
> + kChannelPref, updateChannelPrefValue, PrefValueKind::Default);
> releaseCandidateOnBeta = updateChannelPrefValue.EqualsLiteral("beta");
> }
>
> if (!strcmp(NS_STRINGIFY(MOZ_UPDATE_CHANNEL), "nightly") ||
> !strcmp(NS_STRINGIFY(MOZ_UPDATE_CHANNEL), "aurora") ||
> - !strcmp(NS_STRINGIFY(MOZ_UPDATE_CHANNEL), "beta") ||
> + !strcmp(NS_STRINGIFY(MOZ_UPDATE_CHANNEL), "beta") || developerBuild ||

clang-format changed its mind, I guess?

::: modules/libpref/parser/src/lib.rs:282
(Diff revision 1)
> struct KeywordInfo {
> string: &'static [u8],
> token: Token,
> }
>
> -const KEYWORD_INFOS: &[KeywordInfo; 5] = &[
> +const KEYWORD_INFOS: &[KeywordInfo; 7] = &[

In passing, AFAIK, this could actually me [KeywordInfo; 7] (without the ref)

Comment on attachment 8956311
Bug 440908 - Convert sticky prefs in default pref files to the new syntax.

https://reviewboard.mozilla.org/r/225186/#review231216

> clang-format changed its mind, I guess?

No, chutten changed that code in bug 1435753. I generally run `./mach clang-format -p modules/libpref`. Perhaps I should just run `./mach clang-format` instead...

https://hg.mozilla.org/integration/mozilla-inbound/rev/edb57fbc6beac233b12486fa7d7381220339de0f
Bug 440908 - Remove gIsAnyPrefLocked. r=glandium

https://hg.mozilla.org/integration/mozilla-inbound/rev/b82802657783b6188e320ba966183ae1eedabf62
Bug 440908 - Add support for `sticky` and `locked` attributes to default prefs. r=glandium

https://hg.mozilla.org/integration/mozilla-inbound/rev/d1d9ef8f7c0ecdc6b9d8fa33b8b2a9238e0ad64f
Bug 440908 - Convert sticky prefs in default pref files to the new syntax. r=glandium

https://hg.mozilla.org/mozilla-central/rev/edb57fbc6bea
https://hg.mozilla.org/mozilla-central/rev/b82802657783
https://hg.mozilla.org/mozilla-central/rev/d1d9ef8f7c0e