From 7b9db9e889915cbdcf6394bb077d51d8bbf02ba5 Mon Sep 17 00:00:00 2001 From: Razvan Dimescu Date: Sat, 18 Apr 2026 08:54:34 +0300 Subject: [PATCH] =?UTF-8?q?fix(linux):=20drop=20ProtectHome=3Dtrue=20?= =?UTF-8?q?=E2=80=94=20blocks=20exec=20when=20binary=20lives=20under=20/ho?= =?UTF-8?q?me?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Integration-linux journalctl showed status=203/EXEC: systemd couldn't exec /home/runner/work/numa/numa/target/release/numa because ProtectHome=yes makes /home invisible to the sandboxed process. My local Docker test passed because the binary was at /workspace, not /home. DynamicUser=yes already implies ProtectHome=read-only, which preserves exec access to binaries living under /home (cargo install, source builds, CI) while blocking writes to user $HOMEs. Keep that default rather than over-restricting. Follow-up worth tracking: install_service_linux could copy the binary to /usr/local/bin/numa the way Windows does at windows_service_exe_path, making the unit's ExecStart independent of where `numa install` was invoked from — then we could set ProtectHome=yes again. --- numa.service | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/numa.service b/numa.service index 5380b83..4794033 100644 --- a/numa.service +++ b/numa.service @@ -27,7 +27,10 @@ ConfigurationDirectoryMode=0755 # allow-lists) can be layered on once tested in isolation. NoNewPrivileges=true ProtectSystem=strict -ProtectHome=true +# DynamicUser= sets ProtectHome=read-only by default — leaves /home +# readable so systemd can exec binaries installed under it (cargo install, +# source builds), while blocking writes to user $HOMEs. Don't set =yes: +# that hides /home entirely and fails with status=203/EXEC. PrivateTmp=true PrivateDevices=true ProtectKernelTunables=true