Open Bug 1678999 Opened 2 years ago Updated 3 months ago

Use instead of a single policies.json a split-file approach for policies...

Categories

(Firefox :: Enterprise Policies, enhancement, P5)

78 Branch
enhancement

Tracking

()

People

(Reporter: gaio, Unassigned)

Details

Currently FF (and also TB, indeed) support policies via a single policy.json file; in this way if a configuration management system need different configuration for different (set of) host, it is forced to prepare a different 'policy.json' file for every (set of) host.

It is true that modern configuration management engine support direct in-file editing (take Ansible as an example), but this is a bit 'clumsy' and can lead to trouble (if the editing corrupt the json format, all the policy get discarded).
Also, 'split file' is a modern way of configuring things, see Debian distro that use extensively split file for their configuration.

Consider an example: i need to install FF in my organization; management sector need plugin A and B, production sector need plugin B and C. I need to setup three json file: the base one without plugin, the 'AB' one and the 'BC' one.

A better approach would be to have FF to load policy as 'split file', eg load all the json file in a particular folder: in this way i can check json syntax correctness before uploading the file, and FF policy parser can reject a single json file, not all the policy.
Even direct in-file editing will be safer, if needed, because i can modify a single file and not all the policy.

Staying in my example, in this way i setup the base policy 'policy.json' and the plugin policies 'A.json', 'B.json' and 'C.json'.
With this setup i need only to copy 'policy.json' to all computer, and copy the plugin policies file where needed.

I hope i was clear.

How would we choose which JSON would "win" if there were conflicts?

As for old preferences (AutoConfig) simply (forward) lexicographic order or reverse lexicographic order, eg first policy definition win or last policy definition win.

Distributions and package mantainers typically suggest to 'force' lexicographic order by using prefixes, eg:
000-some-less-important-policy.json
050-mild-important-policy-1.json
050-mild-important-policy-2.json
999-this-have-to-be-the-last.json

(clearly supposing that last wins), or using aaaa...zzzz as prefixes.

Ops forgot... to prevent accidental drop of invalid file in the policy folder, tipically parser does not read 'all file in folder' but 'all file json in folder', eg *.json, so you can put also here README, backup files, ... all stuff you need for your use, it suffices NOT have json extension.

I'll confirm this, but it would be a way future thing.

Severity: -- → N/A
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5

There's another benefit for this which is that different folder paths on Linux systems are deemed to be influenced/controlled by different parties. It's common in systemd (e.g. https://www.freedesktop.org/software/systemd/man/systemd.unit.html defines a search path precedence) to have /etc take precedence over /run over /usr which allows the distributor to set some default stuff in /usr, have some scripts or whatever which could vary it at runtime in /run, and the administrator gets the last word in /etc.

In the Flatpak case (per https://bugzilla.mozilla.org/show_bug.cgi?id=1682462#c31 ), this would provide a place for Firefox to be also look in /app for the default Flatpak policy, and could symlink stuff in to /run (or add some other paths) based on policies being provided from the host system outside the Flatpak.

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