Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
[Security] omarchy debug and omarchy upload log stage root-collected diagnostics at predictable /tmp paths
Reported by Chessing234 · filed Aug 26, 2026Closed upstream on 2026-10-04 by dhh, as not planned.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Two commands assemble system diagnostics at fixed paths under /tmp:
| command | path | contents |
|---|---|---|
omarchy-debug | /tmp/omarchy-debug.log | sudo dmesg, journalctl -b -p 4..1, inxi -Farz, hostname, full package list |
omarchy-upload-log | /tmp/upload-log.txt, /tmp/system-info.txt | fastfetch inventory plus journalctl -b 0 (or -b -1, or the install log) |
/tmp is world-writable. Both scripts open those fixed names with plain truncating redirection under the default umask, so the files land mode 0644 and stay until reboot or tmpfiles cleanup.
What a second local account can actually do on a stock Omarchy machine (fs.protected_regular=1, fs.protected_symlinks=1, sticky /tmp):
- Disclosure. After the victim has run either command, read the leftover 0644 file — including a root-collected kernel ring buffer and journal from
omarchy-debug. Confirmed against a real second unprivileged account. - Pre-created upload name. Create
/tmp/upload-log.txtfirst. Every redirect inomarchy-upload-logthen fails (noset -e), andcurl -F file=@still uploads the attacker's file under the victim's name and prints the URL as a success.
What does not work under those protections (earlier drafts of this issue claimed them): planting a 0666 file for the victim to write into, planting a symlink to redirect the write, or replacing the payload between the last append and curl — sticky bit / fs.protected_* refuse those.
omarchy-debug itself offers "Upload log" as its first menu entry, so (1) and (2) chain.
This is the same class as #7904, which stopped the FIDO2 setup staging its authfile at a predictable /tmp path.
Expected
Stage them somewhere only the owner can reach — the per-user runtime directory, or an unpredictable mktemp name — rather than a fixed name in a directory everyone can write to. Drop any leftover world-readable copies on upgrade.
View raw text
Two commands assemble system diagnostics at fixed paths under `/tmp`: | command | path | contents | | --- | --- | --- | | `omarchy-debug` | `/tmp/omarchy-debug.log` | `sudo dmesg`, `journalctl -b -p 4..1`, `inxi -Farz`, hostname, full package list | | `omarchy-upload-log` | `/tmp/upload-log.txt`, `/tmp/system-info.txt` | fastfetch inventory plus `journalctl -b 0` (or `-b -1`, or the install log) | `/tmp` is world-writable. Both scripts open those fixed names with plain truncating redirection under the default umask, so the files land mode 0644 and stay until reboot or tmpfiles cleanup. What a second local account can actually do on a stock Omarchy machine (`fs.protected_regular=1`, `fs.protected_symlinks=1`, sticky `/tmp`): 1. **Disclosure.** After the victim has run either command, read the leftover 0644 file — including a root-collected kernel ring buffer and journal from `omarchy-debug`. Confirmed against a real second unprivileged account. 2. **Pre-created upload name.** Create `/tmp/upload-log.txt` first. Every redirect in `omarchy-upload-log` then fails (no `set -e`), and `curl -F file=@` still uploads the attacker's file under the victim's name and prints the URL as a success. What does **not** work under those protections (earlier drafts of this issue claimed them): planting a 0666 file for the victim to write into, planting a symlink to redirect the write, or replacing the payload between the last append and `curl` — sticky bit / `fs.protected_*` refuse those. `omarchy-debug` itself offers "Upload log" as its first menu entry, so (1) and (2) chain. This is the same class as #7904, which stopped the FIDO2 setup staging its authfile at a predictable `/tmp` path. ## Expected Stage them somewhere only the owner can reach — the per-user runtime directory, or an unpredictable `mktemp` name — rather than a fixed name in a directory everyone can write to. Drop any leftover world-readable copies on upgrade.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.