Linux: Read lower-precedence policies from $SNAP_DATA/policies in snaps Canonical's Chromium snap carries snap-policies-path.patch, which replaces chrome::DIR_POLICY_FILES with $SNAP_DATA/policies when SNAP_DATA is set. That can't be upstreamed as is: SNAP_DATA is an environment variable, so on a regular deb or rpm install any user could bypass enterprise policy (and the enrollment token, which is also read from DIR_POLICY_FILES) with `SNAP_DATA=/tmp/x google-chrome`. The standard policy directory already works in a snap through the browser-support interface. $SNAP_DATA/policies is still useful where /etc/opt isn't writable (Ubuntu Core) and for per-snap policies, so add it as an additional, lower-precedence source of platform policy: - ConfigDirPolicyLoader takes a vector<ConfigDirectory> in decreasing order of precedence, each with the standard managed/ and recommended/ layout and an optional OwnershipRequirement. Earlier directories win conflicts at the same level. This replaces the single-directory constructor; the only other caller (remoting's PolicyWatcher) is updated. - When an OwnershipRequirement is set on a ConfigDirectory, a policy file in it is only read if the file and every directory from trusted_base_dir down to it are owned by trusted_uid, aren't symlinks and aren't writable by group or others. Symlinks in the configured path are resolved first, since $SNAP_DATA is /var/snap/<name>/current, a symlink to the current revision. This ownership check, not the environment, is the security boundary: an unprivileged user can't create a root-controlled directory under `/`. The check is only available on Linux and Mac, so OwnershipRequirement must not be used elsewhere. - ChromeBrowserPolicyConnector appends $SNAP_DATA/policies (requiring root ownership up to `/`) when GetAppSandbox() is kSnap. - base::VerifyPathControlledByUser() was Mac-only; enable it on Linux too for the ownership check. chrome::DIR_POLICY_FILES and the enrollment token location are unchanged. Bug: 579508504 Change-Id: I3d27066da0cd30570ef03115b9f4b8b24ce59d08 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8706559 Reviewed-by: Lei Zhang <thestig@chromium.org> Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org> Reviewed-by: Nicolas Ouellet-Payeur <nicolaso@chromium.org> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/heads/main@{#1740028} NOKEYCHECK=True GitOrigin-RevId: d0cf1233880531050b5636955fdf936426b94efe
Contains a written down set of principles and other information on //base. Please add to it!
Chromium is a very mature project. Most things that are generally useful are already here and things not here aren't generally useful.
The bar for adding stuff to base is that it must have demonstrated wide applicability. Prefer to add things closer to where they're used (i.e. “not base”), and pull into base only when needed. In a project our size, sometimes even duplication is OK and inevitable.
Adding a new logging macro DPVELOG_NE is not more clear than just writing the stuff you want to log in a regular logging statement, even if it makes your calling code longer. Just add it to your own code.
If the code in question does not need to be used inside base, but will have multiple consumers across the codebase, consider placing it in a new directory under components/ instead.
base is written for the Chromium project and is not intended to be used outside it. Using base outside of src.git is explicitly not supported, and base makes no guarantees about API (or even ABI) stability (like all other code in Chromium). New code that depends on base/ must be in src.git. Code that's not in src.git but pulled in through DEPS (for example, v8) cannot use base.
Owners are added when a contributor has shown the above qualifications and when they express interest. There isn't an upper bound on the number of OWNERS.
Since the primitives provided by //base are used very widely, it is important to ensure they scale to the necessary workloads and perform well under all supported platforms. The base_perftests target is a suite of synthetic microbenchmarks that measure performance in various scenarios:
thread_local, the implementation in //base, the POSIX/WinAPI directly)Regressions in these benchmarks can generally by caused by 1) operating system changes, 2) compiler version or flag changes or 3) changes in //base code itself.
Rust code in base should be organized into very small crates, split up by function. Merging crates is sometimes unavoidable (due to dependency cycles or the orphaning rule).
Rust files should live near the equivalent C++ files (if any), and use the same naming scheme (for example, run_loop.rs, not run_loop_rust.rs).
When adding FFI shims, prefer separate _shim.h files rather than adding code to existing C++ files. This helps avoid circular dependencies with the //base target. It also avoids adding code to commonly-used headers, which can increase compile size by a lot.
Crates which you expect to be widely used should be added to the public_deps of the //base:base_rust target, so that developers can simply depend on //base:base_rust the same way they do with //base.