89ef4efdcf
Historically, we spawned the Seatbelt and Landlock sandboxes in substantially different ways: For **Seatbelt**, we would run `/usr/bin/sandbox-exec` with our policy specified as an arg followed by the original command:d1de7bb383/codex-rs/core/src/exec.rs (L147-L219)For **Landlock/Seccomp**, we would do `tokio::runtime::Builder::new_current_thread()`, _invoke Landlock/Seccomp APIs to modify the permissions of that new thread_, and then spawn the command:d1de7bb383/codex-rs/core/src/exec_linux.rs (L28-L49)While it is neat that Landlock/Seccomp supports applying a policy to only one thread without having to apply it to the entire process, it requires us to maintain two different codepaths and is a bit harder to reason about. The tipping point was https://github.com/openai/codex/pull/1061, in which we had to start building up the `env` in an unexpected way for the existing Landlock/Seccomp approach to continue to work. This PR overhauls things so that we do similar things for Mac and Linux. It turned out that we were already building our own "helper binary" comparable to Mac's `sandbox-exec` as part of the `cli` crate:d1de7bb383/codex-rs/cli/Cargo.toml (L10-L12)We originally created this to build a small binary to include with the Node.js version of the Codex CLI to provide support for Linux sandboxing. Though the sticky bit is that, at this point, we still want to deploy the Rust version of Codex as a single, standalone binary rather than a CLI and a supporting sandboxing binary. To satisfy this goal, we use "the arg0 trick," in which we: * use `std::env::current_exe()` to get the path to the CLI that is currently running * use the CLI as the `program` for the `Command` * set `"codex-linux-sandbox"` as arg0 for the `Command` A CLI that supports sandboxing should check arg0 at the start of the program. If it is `"codex-linux-sandbox"`, it must invoke `codex_linux_sandbox::run_main()`, which runs the CLI as if it were `codex-linux-sandbox`. When acting as `codex-linux-sandbox`, we make the appropriate Landlock/Seccomp API calls and then use `execvp(3)` to spawn the original command, so do _replace_ the process rather than spawn a subprocess. Incidentally, we do this before starting the Tokio runtime, so the process should only have one thread when `execvp(3)` is called. Because the `core` crate that needs to spawn the Linux sandboxing is not a CLI in its own right, this means that every CLI that includes `core` and relies on this behavior has to (1) implement it and (2) provide the path to the sandboxing executable. While the path is almost always `std::env::current_exe()`, we needed to make this configurable for integration tests, so `Config` now has a `codex_linux_sandbox_exe: Option<PathBuf>` property to facilitate threading this through, introduced in https://github.com/openai/codex/pull/1089. This common pattern is now captured in `codex_linux_sandbox::run_with_sandbox()` and all of the `main.rs` functions that should use it have been updated as part of this PR. The `codex-linux-sandbox` crate added to the Cargo workspace as part of this PR now has the bulk of the Landlock/Seccomp logic, which makes `core` a bit simpler. Indeed, `core/src/exec_linux.rs` and `core/src/landlock.rs` were removed/ported as part of this PR. I also moved the unit tests for this code into an integration test, `linux-sandbox/tests/landlock.rs`, in which I use `env!("CARGO_BIN_EXE_codex-linux-sandbox")` as the value for `codex_linux_sandbox_exe` since `std::env::current_exe()` is not appropriate in that case.
64 lines
2.0 KiB
Rust
64 lines
2.0 KiB
Rust
#[cfg(target_os = "linux")]
|
||
mod landlock;
|
||
#[cfg(target_os = "linux")]
|
||
mod linux_run_main;
|
||
|
||
#[cfg(target_os = "linux")]
|
||
pub use linux_run_main::run_main;
|
||
|
||
use std::future::Future;
|
||
use std::path::PathBuf;
|
||
|
||
/// Helper that consolidates the common boilerplate found in several Codex
|
||
/// binaries (`codex`, `codex-exec`, `codex-tui`) around dispatching to the
|
||
/// `codex-linux-sandbox` sub-command.
|
||
///
|
||
/// When the current executable is invoked through the hard-link or alias
|
||
/// named `codex-linux-sandbox` we *directly* execute [`run_main`](crate::run_main)
|
||
/// (which never returns). Otherwise we:
|
||
/// 1. Construct a Tokio multi-thread runtime.
|
||
/// 2. Derive the path to the current executable (so children can re-invoke
|
||
/// the sandbox) when running on Linux.
|
||
/// 3. Execute the provided async `main_fn` inside that runtime, forwarding
|
||
/// any error.
|
||
///
|
||
/// This function eliminates duplicated code across the various `main.rs`
|
||
/// entry-points.
|
||
pub fn run_with_sandbox<F, Fut>(main_fn: F) -> anyhow::Result<()>
|
||
where
|
||
F: FnOnce(Option<PathBuf>) -> Fut,
|
||
Fut: Future<Output = anyhow::Result<()>>,
|
||
{
|
||
use std::path::Path;
|
||
|
||
// Determine if we were invoked via the special alias.
|
||
let argv0 = std::env::args().next().unwrap_or_default();
|
||
let exe_name = Path::new(&argv0)
|
||
.file_name()
|
||
.and_then(|s| s.to_str())
|
||
.unwrap_or("");
|
||
|
||
if exe_name == "codex-linux-sandbox" {
|
||
// Safety: [`run_main`] never returns.
|
||
crate::run_main();
|
||
}
|
||
|
||
// Regular invocation – create a Tokio runtime and execute the provided
|
||
// async entry-point.
|
||
let runtime = tokio::runtime::Runtime::new()?;
|
||
runtime.block_on(async move {
|
||
let codex_linux_sandbox_exe: Option<PathBuf> = if cfg!(target_os = "linux") {
|
||
std::env::current_exe().ok()
|
||
} else {
|
||
None
|
||
};
|
||
|
||
main_fn(codex_linux_sandbox_exe).await
|
||
})
|
||
}
|
||
|
||
#[cfg(not(target_os = "linux"))]
|
||
pub fn run_main() -> ! {
|
||
panic!("codex-linux-sandbox is only supported on Linux");
|
||
}
|