Strip setgid and setuid bits from Windows VM mount directories (#13558)

[szaidi-code]

Closes #13558

Summary

When user directories such as ~/Windows inherit the setgid bit from parent folder permissions, Windows VM mount creation can fail or propagate unexpected permissions.

Changes

• Strip setgid and setuid bits (chmod u-s,g-s) in addition to chmod 0700 in mount source and credentials routines in bin/omarchy-windows-vm.

[sanjyay]

Thanks for working on this fix!

Verification Summary

• Syntax check: bash -n bin/omarchy-windows-vm passes cleanly.
• Test suite: Ran test/shell.d/windows-vm-compose-test.sh in an isolated test environment (22/22 pass).
• Behavioral testing: Verified that chaining chmod 0700 ... && chmod u-s,g-s ... successfully clears the setgid bit on directories that were previously at mode 2777, restoring them to 700.

Observations

1. Prior PR Overlap:
   This change addresses omarchy-windows-vm launch refuses ~/Windows once dockurr sets setgid (chmod 0700 leaves mode 2700) #13558, which is also addressed by open PR Clear setgid when hardening Windows VM mount sources #13750 ("Clear setgid when hardening Windows VM mount sources"). It may be worth coordinating to avoid duplicate effort.

2. Single-Invocation Mode (chmod 00700):
   GNU coreutils chmod preserves set-group-ID bits on directories when using 3- or 4-digit numeric modes (0700), but as documented in man chmod:

   "To clear these bits for directories with a numeric mode requires an additional leading zero like 00755..."

   Using the 5-digit numeric mode chmod 00700 -- ... clears setuid, setgid, and sticky bits in a single command and syscall, rather than spawning two separate processes via chmod 0700 ... && chmod u-s,g-s ....

3. Automated Regression Coverage:
   PR Clear setgid when hardening Windows VM mount sources #13750 adds an automated test case in test/shell.d/windows-vm-compose-test.sh starting from a 2777 directory and verifying it normalizes to 700 and satisfies caller verification. If proceeding with this PR, including equivalent test coverage would be beneficial.

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

[jandrusk]

Triage (not posted): Explicit chmod u-s,g-s after chmod 0700 matches the large Windows VM setgid cluster (#13558, #13750, #13213, #13154, #12323, #12019, …). The change itself looks correct and minimal.

Please coordinate with maintainers so one canonical PR lands this (several AnPod/stacked PRs also bundle the same harden). No objection to the patch; avoid merging the same three-line fix via many stacked branches.

[omarchybot]

Thanks for this. The diagnosis is right: chmod 0700 keeps setgid on a directory, so the 2777 that dockurr/windows leaves on ~/Windows ends up as 2700 and the exact-700 check in prepare_caller_mounts refuses the launch. Running chmod u-s,g-s after it does clear the bit at both hardening sites.

It is one of several open pull requests fixing #13558 / #9334 the same way, so I compared them rather than verifying this one separately: #12323, #13750, #13213, #13154, #10338, #10411 and #9605 all change the same chmod. #12323 is the one I would bring forward. It clears the bits in a single chmod u=rwx,go=,a-s (no second process, no window between the two calls), adds regression tests for setgid and setuid sources both behind live anchors and after the binds are recreated, and prints the path and mode when hardening still fails instead of exiting silently. This pull request has no test, and it also changes the credentials directory, which the launch failure does not involve.

Checked by Claude Opus 5.5 reading all eight diffs against quattro, and independently by Codex Medium, which ranked #12323 first for the same reasons; independence is not guaranteed. Nothing was run on a worker for this one, since its competitor is the fix being verified. Which of these lands is the maintainer's call, so this is now waiting on them.

[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