LibSandbox: Allow utimensat() in the filesystem write seccomp group - #10748
LibSandbox: Allow utimensat() in the filesystem write seccomp group#10748awesomekling wants to merge 1 commit into
Conversation
The Compositor sandbox provisions a read-write landlock path for Mesa's shader disk cache and calls allow_filesystem_writes(), but the seccomp policy did not include utimensat(). Mesa updates cache entry mtimes for LRU eviction, and glibc routes the whole utime() family through utimensat() on modern kernels, so the kernel killed the Compositor with SIGSYS the first time it touched a cache entry. That tore down every in-flight test in a full test-web run and made the runner itself abort while respawning clients. Text/input/wpt-import/webidl/current-realm.html reproduced the crash deterministically and passes again with utimensat() allowed.
📝 WalkthroughWalkthroughChangesutimensat seccomp support
Estimated code review effort: 2 (Simple) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Libraries/LibSandbox/Seccomp.cpp`:
- Around line 866-868: Remove the utimensat entry from the shared
filesystem-write policy in the seccomp policy setup. Do not allow raw utimensat
access globally; if Mesa shader-cache eviction still requires timestamp updates,
route them through trusted code restricted to the cache directory or apply a
narrowly scoped, cache-specific allowlist.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 25410734-199e-432a-8527-51f55eea3928
📒 Files selected for processing (1)
Libraries/LibSandbox/Seccomp.cpp
| // NB: Mesa's shader disk cache updates entry mtimes for LRU eviction, and glibc routes the | ||
| // whole utime() family through utimensat() on modern kernels. | ||
| SECCOMP_APPEND_ALLOW_SYSCALL_IF_DEFINED(*this, utimensat); |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== Seccomp.cpp relevant section ==\n'
sed -n '820,900p' Libraries/LibSandbox/Seccomp.cpp
printf '\n== Search for utimensat and Landlock references ==\n'
rg -n "utimensat|utime|Landlock|restrict_filesystem_with_landlock|shader cache|filesystem-write" Libraries/LibSandbox -SRepository: LadybirdBrowser/ladybird
Length of output: 5528
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== Sandbox.cpp Landlock section ==\n'
sed -n '380,520p' Libraries/LibSandbox/Sandbox.cpp
printf '\n== Search utimensat call sites ==\n'
rg -n "\butimensat\b|\butime(ns)?\b" -S .Repository: LadybirdBrowser/ladybird
Length of output: 7233
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== allow_filesystem_writes call sites ==\n'
rg -n "allow_filesystem_writes\(" Libraries/LibSandbox -S
printf '\n== Restrict filesystem call sites ==\n'
rg -n "restrict_filesystem_with_landlock\(" -S .Repository: LadybirdBrowser/ladybird
Length of output: 1074
🌐 Web query:
Landlock utimensat utime family support handled_access_fs timestamp updates kernel documentation
💡 Result:
As of July 18, 2026, the Linux Landlock LSM does not support restricting the utime(2) family of system calls (which includes utimensat(2)) via the handled_access_fs mechanism [1][2][3]. Official kernel documentation explicitly states that it is currently not possible to restrict several file-related actions, including those accessible through utime(2), within a Landlock domain [1][2]. Consequently, operations that update file timestamps (such as utimes, utime, and utimensat) remain outside the scope of current Landlock filesystem access control bitmasks [1][3]. The documentation notes that future evolutions of Landlock are intended to enable the restriction of these syscalls [1][2][3].
Citations:
- 1: https://origin.kernel.org/doc/html/latest/userspace-api/landlock.html
- 2: https://docs.kernel.org/userspace-api/landlock.html
- 3: https://kernel.org/doc/html/latest/userspace-api/landlock.html
Authorization Bypass (CWE-863): Incorrect Authorization
Reachability: External
Keep utimensat() out of the shared filesystem-write policy
Landlock does not restrict the utime(2) family, so allowing raw utimensat() here lets a sandboxed process retimestamp any DAC-accessible path outside the Landlock-granted tree. If Mesa needs this for shader-cache eviction, broker it through trusted code that only targets the cache directory, or gate it behind a much narrower allowlist.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Libraries/LibSandbox/Seccomp.cpp` around lines 866 - 868, Remove the
utimensat entry from the shared filesystem-write policy in the seccomp policy
setup. Do not allow raw utimensat access globally; if Mesa shader-cache eviction
still requires timestamp updates, route them through trusted code restricted to
the cache directory or apply a narrowly scoped, cache-specific allowlist.
The Compositor sandbox provisions a read-write landlock path for Mesa's shader disk cache and calls allow_filesystem_writes(), but the seccomp policy did not include utimensat(). Mesa updates cache entry mtimes for LRU eviction, and glibc routes the whole utime() family through utimensat() on modern kernels, so the kernel killed the Compositor with SIGSYS the first time it touched a cache entry. That tore down every in-flight test in a full test-web run and made the runner itself abort while respawning clients.
Text/input/wpt-import/webidl/current-realm.html reproduced the crash deterministically and passes again with utimensat() allowed.