dc4db77918
This reverts commit57368cb688. Reason for revert: crbug.com/406443772 Original change's description: > Reland "Use string_view in logging and trace_event location" > > This is a reland of commit5439f8eb1e> > Original change's description: > > Use string_view in logging and trace_event location > > > > Changes the LogMessage class to use a string_view for file names. This > > required a matching change in trace_event: a const char* string was > > passed from logging code, but there is no safe way to get a const > > char* from a string_view since the latter may not be null-terminated. > > > > Many clients of base/logging.h are updated to use string_view as well. > > > > Code which attempts to pass a string_view to a LogMessage by its data > > pointer already exists: > > https://source.chromium.org/chromium/chromium/src/+/main:ash/quick_pair/common/logging.cc;l=49;drc=c6c99d03b1d2f4fab91d6be8665f81b540690c73 > > https://source.chromium.org/chromium/chromium/src/+/main:components/cross_device/logging/logging.cc;l=30;drc=00704dbac4f63b2476aac319572ffc42c9b71fc2 > > > > Desire for Rust logging support prompted this change. In principle a > > Rust log facility can be a thin wrapper around the base logging > > implementation, but Rust has almost no support for null-terminated > > strings. Instead, Rust provides a string_view equivalent built in to > > the language. This change enables Rust code to pass file names > > obtained by language-specific macros to the C++ implementation. > > > > Bug: None > > Change-Id: I21b4f1c945b70d54f66d80adf3dcda1fe5a39f71 > > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5765705 > > Reviewed-by: Peter Boström <pbos@chromium.org> > > Auto-Submit: Collin Baker <collinbaker@chromium.org> > > Commit-Queue: Collin Baker <collinbaker@chromium.org> > > Reviewed-by: Stephen Nusko <nuskos@chromium.org> > > Reviewed-by: Daniel Cheng <dcheng@chromium.org> > > Owners-Override: Daniel Cheng <dcheng@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#1436283} > > Bug: None > Change-Id: I725bac881a160caa6d97e7480bc4047b460fae34 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6387020 > Commit-Queue: Collin Baker <collinbaker@chromium.org> > Reviewed-by: Peter Boström <pbos@chromium.org> > Owners-Override: Daniel Cheng <dcheng@chromium.org> > Reviewed-by: Daniel Cheng <dcheng@chromium.org> > Reviewed-by: Stephen Nusko <nuskos@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1437625} Bug: None No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: Ia4a01ddf6af5068d38b13971e09eb8146bd4d2d2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6395097 Commit-Queue: Collin Baker <collinbaker@chromium.org> Owners-Override: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#1438193}
Sandbox Library
This directory contains platform-specific sandboxing libraries. Sandboxing is a technique that can improve the security of an application by separating untrustworthy code (or code that handles untrustworthy data) and restricting its privileges and capabilities.
Each platform relies on the operating system's process primitive to isolate code into distinct security principals, and platform-specific technologies are used to implement the privilege reduction. At a high-level:
mac/uses the Seatbelt sandbox. See the detailed design for more.linux/uses namespaces and Seccomp-BPF. See the detailed design for more.win/uses a combination of restricted tokens, distinct job objects, alternate desktops, and integrity levels. See the detailed design for more.
Built on top of the low-level sandboxing library is the
//sandbox/policy component, which provides concrete
policies and helper utilities for sandboxing specific Chromium processes and
services. The core sandbox library cannot depend on the policy component.