Closed Bug 1469629 Opened 6 years ago Closed 4 years ago

Read Linux policy from etc/opt directory

Categories

(Firefox :: Enterprise Policies, enhancement, P3)

enhancement

Tracking

()

VERIFIED FIXED
Firefox 78
Tracking Status
firefox-esr68 --- verified
firefox62 --- wontfix
firefox76 --- wontfix
firefox77 --- verified
firefox78 --- verified

People

(Reporter: mkaply, Assigned: mkaply)

References

Details

Attachments

(1 file)

On Linux, we should be reading the policies from a central location, not the distribution directory.

This is consistent with other Linux policies. See how Chrome does it:

https://www.chromium.org/administrators/linux-quick-start
Priority: P1 → P3

cref: https://github.com/mozilla/policy-templates/issues/291

IIUC, the FF policy file ONLY "goes into firefox/distribution, where firefox is the installation directory for firefox, which varies by distribution.", and is NOT searched for in any USER-persistent location.

For the use-case of devs/users that frequently download, build & install new FF instances, this requires constant updating of these per-distribution policy files.

For locked-down-dinosaur-enterprise mgmt, sure, I understand the "in the app dir" approach.
But, for this^^ use-case -- multiple/changing installs -- that becomes a mgmt nightmare.

A user-persistent location option for the POLICY files solves that issue.

Something in the USER's "~/.mozilla/...", or even something in "/usr/local/etc/...:/opt/etc/...:/etc/...", would be useful.

Anything persistent -- outside of the APP dir tree -- would do ...

I'd suggest "/.mozilla/policies", since the policies' data search path already, apparently, includes "/.mozilla/certificiates"

hmm ... formatting :-/

I'd suggest

~/.mozilla/policies,

since the policies' data search path already, apparently, includes

~/.mozilla/certificiates

~/.mozilla/policies,

That could work, but I'm curious, is /usr/local/etc a thing? That seems like a good place because it matches the etc where I was going to put the global file...

Depends on what your def'n of "thing" is ...

It certainly works if you create the dir, and tell your apps about it.

I personally put my non-distro-installed "stuff" in /usr/local/...
E.g., /usr/local/firefox, /usr/local/thunderbird (often as symlinks to /usr/local/firefox-release-v64.0 etc etc)

Some, but NOT all, distros install apps into /usr/local path.
For those that do, /usr/local/etc typically comes along for the ride.

I.e., YMMV.

I think it's a fair assumption that user's homedir will always be there. And, for me, policy is a per-user 'thing' ... so "~" makes sense.

Since

https://wiki.mozilla.org/CA/AddRootToFirefox

already id's:

	Linux
		/usr/lib/mozilla/certificates
		/usr/lib64/mozilla/certificates
		~/.mozilla/certificates

it make sense to me to simply have the equivalent

	Linux
		/usr/lib/mozilla/policies
		/usr/lib64/mozilla/policies
		~/.mozilla/policies

no?

PGNet Dev:

Can you take a look at this proposal?

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

Flags: needinfo?(pgnet.dev+mozbugs)

@mkaply

took a quick look (on the road, atm). iiuc, they're proposing /run, or /var/run

doesn't make a lot of sense to me, as it's nonpersistent

e.g., here,

mount | grep run
	tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
	tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=779160k,mode=700)
	tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=779160k,mode=700,uid=1000,gid=100)

ls -ald /run /var/run
	drwxr-xr-x 47 root root 1.4K Sep 25 09:38 /run/
	lrwxrwxrwx  1 root root    6 Jul 19  2014 /var/run -> ../run/

as just a couple points of reference,

https://wiki.archlinux.org/index.php/Tmpfs
https://docs.oracle.com/cd/E19455-01/805-7228/fsoverview-19/index.html
https://superuser.com/questions/1056926/is-var-run-user-uid-the-new-var-run-for-pid-files

i suppose you could get systemd units to populate the tmpfs dirs from some config on startup, but that seem like unnecessary layers of complication. tying config location to non-mozilla-standard-locations, or more to the point, systemd-specific locations, seems unwise.

Flags: needinfo?(pgnet.dev+mozbugs)

The original Redhat Bugzilla request (https://bugzilla.redhat.com/show_bug.cgi?id=1754460 - which is linked in bug 1583466) says that something called 'Fleet Commander' can setup profiles for users in /run/...

It looks like Fleet Commander is an 'application that allows you to manage the desktop configuration of a large network of users and workstations/laptops' - so I guess, Fleet Commander will create profile.json files for each user at system start time - in a location that it uses for other stuff it sets up for each user - that I guess is readable, but not writable by the user ?

i.e. it doesn't matter if the location is non-persistent, as I guess it will always exist by the time the user starts running Firefox on a Fleet Commander controlled workstation ?

On a related matter, I don't think using ~/.mozilla/policies as a location for policies makes any sense - the point of policies is for an Administrator to lock down whatever for users - and as ~/.mozilla/policies is owned/writable by the user, then the user could change them ?

Yeah, I don't totally claim to understand any of this. the original intent of this bug was to allow system wide policies in etc. I'm not sure what to do about user policies because they are writable as you said.

And if bug 1583466 is a completely unique that only works for Fleet commander, I'm not sure that belongs in firefox.

(In reply to Mike Kaply [:mkaply] from comment #8)

Yeah, I don't totally claim to understand any of this. the original intent of this bug was to allow system wide policies in etc. I'm not sure what to do about user policies because they are writable as you said.

And if bug 1583466 is a completely unique that only works for Fleet commander, I'm not sure that belongs in firefox.

bug 1583466 is not unique for Fleet commander, Fleet commander is only a tool which uses it.
The directory in question (/run/user/$UID) is former /tmp, anyone can use it.

(In reply to James Pearson from comment #7)

The original Redhat Bugzilla request (https://bugzilla.redhat.com/show_bug.cgi?id=1754460 - which is linked in bug 1583466) says that something called 'Fleet Commander' can setup profiles for users in /run/...

It can install policy to /run/user/$UID/firefox which is an alternative to hack user profile directly.

It looks like Fleet Commander is an 'application that allows you to manage the desktop configuration of a large network of users and workstations/laptops' - so I guess, Fleet Commander will create profile.json files for each user at system start time - in a location that it uses for other stuff it sets up for each user - that I guess is readable, but not writable by the user ?

Yes it's writable by user too. AFAIK it's former /tmp dir.

i.e. it doesn't matter if the location is non-persistent, as I guess it will always exist by the time the user starts running Firefox on a Fleet Commander controlled workstation ?

Yes, that correct.

On a related matter, I don't think using ~/.mozilla/policies as a location for policies makes any sense - the point of policies is for an Administrator to lock down whatever for users - and as ~/.mozilla/policies is owned/writable by the user, then the user could change them ?

AFAIK The policy applied by FleetComander to /run/user/$UID/firefox can be overridden by user, it's something like default setup, default bookmarks etc.

Status: NEW → ASSIGNED
Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/872c44be1599
Read system level policies on Linux if available. r=stransky
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 78

Comment on attachment 9146602 [details]
Bug 1469629 - Read system level policies on Linux if available. r?stransky

Beta/Release Uplift Approval Request

  • User impact if declined: No way to set system wide linux policy.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Add policy file to etc/firefox/policies.json and verify it takes effect.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Policy only.
  • String changes made/needed:

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Policy only.
  • User impact if declined: No way to set system wide linux policy.
  • Fix Landed on Version: 78
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Policy only, linux only.
  • String or UUID changes made by this patch:
Attachment #9146602 - Flags: approval-mozilla-esr68?
Attachment #9146602 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Comment on attachment 9146602 [details]
Bug 1469629 - Read system level policies on Linux if available. r?stransky

Looks safe and was reviewed by RedHat, uplift approved for 77 beta 8 and 68.9.0, thanks.

Attachment #9146602 - Flags: approval-mozilla-esr68?
Attachment #9146602 - Flags: approval-mozilla-esr68+
Attachment #9146602 - Flags: approval-mozilla-beta?
Attachment #9146602 - Flags: approval-mozilla-beta+

This issue is verified fixed using Firefox 78.0a1 (BuildID:20200521214934), Firefox 77.0b9 (BuildID:20200521224544) and Firefox 68.9.0esr (provided in comment 17) on Ubuntu 18.04 64bit.

Policies can be set system wide by placing the policies.json file inside the etc/firefox/policies/ path. Also, system wide policies are successfully overriding the policies placed in the distribution folder.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: