Skip to content

Clear setgid when hardening the Windows VM data directories - #11833

Closed
devYRPauli wants to merge 1 commit into
omacom:quattrofrom
devYRPauli:fix/windows-vm-setgid-mode
Closed

devYRPauli wants to merge 1 commit into
omacom:quattrofrom
devYRPauli:fix/windows-vm-setgid-mode

Conversation

@devYRPauli

Copy link
Copy Markdown

Fixes #11741.

chmod keeps setuid and setgid on a directory for every numeric mode. Measured with GNU coreutils 9.1:

start mode command result
2755 chmod 700 2700
2755 chmod 0700 2700
3755 chmod u=rwx,go= 2700
3755 chmod u=rwx,go=,ug-s 700

prepare_caller_mounts runs chmod 0700 on the two pinned sources, then requires stat -Lc '%a' to report 700. A setgid ~/.windows or ~/Windows reports 2700, so the check fails and the function returns 1.

assert_mounts_safe calls it as prepare_caller_mounts || return 1 with no message. Every caller of assert_mounts_safe is a privileged action, so remove and launch stop with no output.

The fix uses chmod u=rwx,go=,ug-s, the shortest symbolic form that clears both bits. prepare_user_mount_sources hardens the same two directories with the same numeric mode, so it gets the same change.

The branch that rejects a wrong mode now prints a reason. Every other refusal in assert_mounts_safe already names one.

Test

test/shell.d/windows-vm-compose-test.sh already asserts stat -Lc '%a' == 700 on both directories after the legacy migration. The fixture for that case now sets g+s on them before the migration runs.

Measured in a Debian bookworm container as a non-root user, inside the test's own unshare --user --map-current-user --keep-caps --mount namespace:

tree result
base 22 ok, rc 0
base plus the new fixture 5 ok, rc 1, stops at the migration case
this branch 22 ok, rc 0

windows-vm-test.sh, windows-vm-mount-boundary-test.sh, privileged-heredoc-test.sh and bin-style-test.sh give the same result on base and on this branch.

chmod keeps setuid and setgid on a directory for every numeric mode, so
chmod 0700 on a setgid ~/.windows or ~/Windows leaves mode 2700. The mode
check in prepare_caller_mounts requires 700, so it returns 1 and every
privileged action stops. Use the symbolic mode u=rwx,go=,ug-s, which
clears both bits.

Print a reason on that branch. assert_mounts_safe names a reason for
every other refusal, so this one failed with no output at all.

The regression fixture sets g+s on the legacy source directories in the
migration case of windows-vm-compose-test.sh.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
devYRPauli added a commit to devYRPauli/devYRPauli that referenced this pull request Sep 14, 2026
Open external pull requests: 40 -> 41. The new one is omacom/omarchy#11833,
which clears the setgid bit when the Windows VM data directories are
hardened, so the mode assert can pass.

Merged stays at 97 across the same 38 projects. Upstream issues stay at 16.
Closed unmerged stays at 37.

No table row moved. The table still covers 52 merges across 11 projects, so
the remainder stays at 45 across 27.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@spuder

spuder commented Sep 14, 2026

Copy link
Copy Markdown

@devYRPauli

Copy link
Copy Markdown
Author

You are right. I searched PRs, not issues, and I searched the wrong term. There are 18 other open PRs for this bug. Three predate mine by two weeks: #9322, #9414 and #9504, all opened on August 31. Closing mine.

One note for whoever picks one of those up. chmod 0700 on a setgid directory leaves it at 2700, so a fix that keeps a numeric mode does not clear the bit. #9322 uses chmod u=rwx,go=,a-s and #9414 uses chmod a-s,u=rwx,go=. Both are correct. #9322 also carries a test.

@devYRPauli devYRPauli closed this Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

omarchy-windows-vm remove/launch silently fails when ~/Windows has a setgid bit (chmod numeric mode can't clear it)

2 participants