Clear setgid when hardening Windows VM mount sources

[dhiasalhiQ]

The dockurr/windows container runs chmod 2777 /shared on an empty share, which lands on ~/Windows. For directories, GNU chmod keeps setuid/setgid when given a 3 or 4 digit octal mode, so chmod 0700 left it at 2700. mounted_leaf_matches and the post-chmod check in prepare_caller_mounts require exactly 700, so every later launch failed with the generic "Failed to start Windows VM!".

This uses chmod 00700 in the two places that harden the mount sources. The five-digit mode is the documented way to clear those bits numerically. It adds a case to windows-vm-compose-test.sh that starts from a 2777 share and checks that it ends up at 700 and still verifies.

I couldn't run windows-vm-compose-test.sh myself: it needs unprivileged mount namespaces, and I only had a Windows machine. bash -n passes on both files.

Fixes #13558

🤖 Generated with Claude Code

[sanjyay]

This is an independent community review and unaffiliated with the Omarchy team, intended to help prepare PRs for their review.

Tested commit 5fc4357c09c85bbf0e67295d20026c5d7feb7d0f in a clean Omarchy test environment.

Verification Summary

• Base behavior on quattro: GNU coreutils chmod preserves the setgid bit on directories when given a 3- or 4-digit octal mode (0700), leaving ~/Windows at mode 2700 after the container applies chmod 2777 /shared. The exact 700 permission checks in prepare_caller_mounts and mounted_leaf_matches subsequently abort every subsequent launch with Failed to start Windows VM!.
• PR behavior: Using 5-digit octal mode 00700 explicitly clears special bits (including setgid) on directories, properly restoring the mount sources to 700.
• Automated test suite:
  • Successfully ran test/shell.d/windows-vm-compose-test.sh inside an unprivileged user/mount namespace: all 23/23 assertions pass, including the new regression test case (ok - hardening clears the setgid bit the container leaves on the shared source).
  • Tested against base quattro: the new regression test accurately fails on base during caller mount preparation (shared_mode=2700 != 700).
  • Syntax check (bash -n) and whitespace checks pass cleanly.

Test details

$ bash test/shell.d/windows-vm-compose-test.sh
ok - writer emits fixed anchors bound to exact private source inodes
ok - hardening clears the setgid bit the container leaves on the shared source
ok - input cannot inject a host path or compose field
ok - password with quote, backslash, and dollar round-trips
ok - privileged action dispatch is allowlisted
ok - pkexec target is only the canonical packaged regular file, never a PATH symlink
...
ok - disk-space checks follow the storage symlink target

$ git diff --check
$ bash -n bin/omarchy-windows-vm test/shell.d/windows-vm-compose-test.sh

If you'd prefer not to receive these independent reviews on your PRs, reply to this comment and say so, and I won't review your future PRs.

[jandrusk]

chmod 00700 is the correct GNU fix for clearing setgid that 0700 leaves on a directory after dockurr's chmod 2777 /shared. Test case from a 2777 share → 700 looks right.

This is a large duplicate cluster — please coordinate so only one lands:

• Clear setgid when hardening Windows VM mount sources #13213, Clear setgid when hardening Windows VM directories #12323, Strip stray special mode bits when hardening Windows VM directories #13154 (same chmod fix PRs)
• Issues: omarchy-windows-vm launch refuses ~/Windows once dockurr sets setgid (chmod 0700 leaves mode 2700) #13558, omarchy-windows-vm launch permanently fails after first VM boot (chmod 0700 doesn't clear setgid on ~/Windows) #12134, omarchy-windows-vm launch fails once ~/Windows carries the setgid bit (chmod 0700 never clears it) #12333, omarchy-windows-vm launch fails on every run after the first: chmod 0700 leaves setgid on ~/Windows #13244, omarchy-windows-vm: launch/migration fails when ~/Windows has setgid bit (chmod 0700 keeps it, check requires 700) #12624, Fix the Windows VM refusing to start after its first launch #10338
• Note: Refuse to run omarchy-update as root #13660 / Drop pam_faillock preauth silent so lockouts are visible #13652 historically bundled this fix with unrelated changes; confirm whether those still carry it before merging another copy.

Happy with this PR as the survivor if maintainers want the smallest dedicated patch + test.

[omarchybot]

Reviewed and verified on a disposable Omarchy worker (coreutils 9.11). The fix is right: chmod 0700 on a 2777 directory leaves 2700 there, and chmod 00700 gives 700, which is what mounted_leaf_matches and the check in prepare_caller_mounts require.

test/shell.d/windows-vm-compose-test.sh fails on quattro at the new case (the privileged writer refuses the 2700 source and exits 2) and passes 23/23 on this branch. windows-vm-mount-boundary-test.sh and windows-vm-test.sh pass too.

I pushed one test-only commit, a27373c. The case called prepare_user_mount_sources before write, so the user-side chmod cleared setgid before prepare_caller_mounts ever saw it, and reverting the privileged fix still passed. Now the writer meets the 2777 source itself, and the user-side hardening is checked separately. Reverting either chmod on its own now fails the test.

The second opinion, Codex at medium effort, reviewed the final head and found nothing. It raised the test gap above in an earlier round. Comparing this with #13800 and #14093, which fix the same bug, it also preferred this one, as I did. Independence is not guaranteed. #13800 reaches the same modes with a second chmod u-s,g-s, but it also changes the credentials directory and adds no test. #14093 fixes only the privileged site and bundles an unrelated RDP retry loop.

One thing outside this PR keeps it from being marked ready. ./test/cli fails on quattro itself at "vscode generated theme references current theme file". The test expects a symlink, but omarchy-theme-set-vscode deliberately writes a real file. This waits on the maintainer.

[greptile-apps]

Confidence Score: 5/5

[High risk] Changes file permissions hardening in VM mount setup.

The PR appears safe to merge; no actionable issue was identified.

Summary

The PR changes both Windows VM mount-source hardening paths to use a five-digit chmod mode, clearing directory setgid so the existing exact-700 checks can pass. It adds regression coverage for a setgid shared source.

_{Reviews (1) · Last reviewed commit: "Cover each setgid hardening site on its ..."}

[omarchybot]

Closing this alternative after #12323 merged into quattro. The merged fix explicitly clears setuid/setgid in both mount-source hardening paths, keeps the exact mode-700 boundary, adds a diagnostic, and covers this launch/install failure. This alternative is no longer needed for that bug.

Scope checked by GPT-6 in Codex and Codex Medium against the discussion and landed change; review independence is not guaranteed. No tests were rerun for this cleanup.

Omabot on behalf of DHH