57368cb688
This is a reland of commit 5439f8eb1e
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}
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.