1386460 - Remove MOZ_DEVELOPER_REPO_DIR and MOZ_DEVELOPER_OBJ_DIR

Status: NEW

(Core :: Security: Process Sandboxing, enhancement, P3)

Description

[Haik Aftandilian [:haik]]

Our Mac and Linux content sandboxing implementations no longer depend on the MOZ_DEVELOPER_REPO_DIR and MOZ_DEVELOPER_OBJ_DIR environment variables for unpackaged dev builds. On Mac, the build puts the paths to these directories in the .plist files in the app bundle. On Linux, symlinks to the repo/object dir are handled by the implementation and don't need to be special-cased. Windows doesn't need the vars because the Windows build doesn't use symlinks.

There is one instance where knowing the repo dir is still required on Linux. On an unpackaged (dev) build, when loading an unpacked extension, the extension remoting code in the parent checks that web-accessible-resource files loaded by the child don't resolve to files outside of the extension directory. For this check, we use the repo path to allow unpacked extensions on dev builds to use symlinks to resources in the repo dir.

A user running ./<object-dir>/dist/bin/firefox withouth setting MOZ_DEVELOPER_REPO_DIR on Linux will encounter errors on dev builds for system extensions because they symlink back to the repo dir. There are also some ./mach commands that don't set MOZ_DEVELOPER_REPO_DIR.

I think it would be OK to skip the directory check on Linux for unpacked extension loads on dev builds. We have work going on in Bug 1382697 - "Detect filesystem and link support in configure" and Bug 1380416 - "Investigate using hardlinks instead of symlinks in the dev build on mac/linux" to change the build to not depend on symlinks which would avoid this issue.

Comment 1

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #0)
> I think it would be OK to skip the directory check on Linux for unpacked
> extension loads on dev builds.

A better approach would be to check if the extension directory is within the "appdir" as that is an indication the extension is a system extension.

Comment 2

[Haik Aftandilian [:haik]]

I'm going to address the ExtensionProtocolHandler Linux issue in bug 1386832. And plan to remove the ExtensionProtocolHandler MOZ_DEVELOPER_REPO_DIR dependency in that fix too.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 4

[Haik Aftandilian [:haik]]

It appears we still need to whitelist $PROFILE/extensions because tests install system addons there, but we shouldn't need it for WebExtensions. On my systems I found [e-mail], [e-mail]. Bug 1393805 added a whitelisted directory on Mac, Windows, and Linux to use for installing legacy system addons and we might be able to move these addons there for testing instead. It's not in the profile directory:

Windows:
<user_home>\AppData\Roaming\Mozilla\SystemExtensionsDev

Mac:
~/Library/Application Support/Mozilla/SystemExtensionsDev

Linux:
~/.mozilla/systemextensionsdev

Will file a blocking bug on this after I look into it some more.

Comment 5

[Haik Aftandilian [:haik]]

The above comment 4 was made on the wrong bug. Please ignore.