bug: sigset_t is only partly initialized under musl before assume_init #5187

User Story

I run OpenShell sandboxes with the Podman and Kubernetes drivers, and I read through the isolation core (openshell-sandbox, openshell-binary-identity, openshell-isolation-interface) at 00528d24a. This item comes from reading the code. I have not hit it in production. It is one line of the umbrella issue #5179.

Problem Statement

crates/openshell-sandbox/src/main.rs:780 (block_launcher_signals) and :834 (install_child_signal_mask, inside the pre_exec hook) create a MaybeUninit<libc::sigset_t>, call sigfillset/sigemptyset, and then assume_init(). The sandbox ships as a static musl binary. On 64-bit musl sigset_t is 128 bytes, but musl's sigfillset and sigemptyset write only the first 8 bytes on x86_64 and aarch64, so 120 bytes stay uninitialized. Reading them as an initialized value is undefined behavior in Rust. The // SAFETY: comments are accurate for glibc but not for musl.

Impact / Why This Matters

In practice musl passes only 8 bytes to rt_sigprocmask, so the mask applied today is the intended one and no workload input reaches either site. It is still undefined behavior that a future compiler or libc change can turn into a real bug.

Acceptance Criteria

• Both sites start from MaybeUninit::zeroed() (or use nix::sys::signal::SigSet::all()/SigSet::empty()).
• The // SAFETY: comments are corrected.
• CI runs Miri or an equivalent check on the changed function if practical.

Reproduction Steps

Found by reading the code; not reproduced live. Read sigfillset and sigemptyset in the musl source bundled with the build (zig) and compare against size_of::<libc::sigset_t>() for the musl target.

Environment

• OpenShell: main at 00528d24a
• OS: Fedora 44, Linux 7.2.14
• Deployment: Podman driver (local gateway); code read for the Kubernetes driver too