Skip to content

fix(windows-vm): strip setgid bit on shared folder to preserve 0700 mount safety - #11891

Open
szaidi-code wants to merge 1 commit into
omacom:quattrofrom
szaidi-code:fix/windows-vm-shared-setgid-mount-failure
Open

szaidi-code wants to merge 1 commit into
omacom:quattrofrom
szaidi-code:fix/windows-vm-shared-setgid-mount-failure

Conversation

@szaidi-code

Copy link
Copy Markdown

Problem

When running dockurr/windows via omarchy-windows-vm, Samba or the container's initialization sets the setgid bit on the bound shared folder (~/Windows), resulting in directory permissions 2700 instead of 0700.

On Linux / BTRFS, numeric chmod 0700 does not clear an existing setgid bit on a directory. Because prepare_caller_mounts() strictly enforces that both storage and shared directories must be mode 700 ([[ $storage_mode != 700 || $shared_mode != 700 ]]), every subsequent launch of the Windows VM fails.

Fixes #11879 (part 1)

Solution

  1. In prepare_caller_mounts(), use chmod 00700 and explicitly run chmod ug-s on the pinned file descriptors to strip any setgid/setuid bits left by container services before checking mode 700.
  2. In mounted_leaf_matches(), also clear chmod ug-s before comparing the directory mode against 700.
  3. In prepare_user_mount_sources(), use chmod 00700 and chmod ug-s.
  4. Added a regression test to test/shell.d/windows-vm-mount-boundary-test.sh verifying that an existing 2700 (setgid) shared directory has setgid stripped and maintains verified 0700 privacy across mount checks.

Verification

  • Ran test/shell.d/windows-vm-mount-boundary-test.sh (all 10 checks pass).
  • Ran all Windows VM test suites (windows-key-test.sh, windows-vm-compose-test.sh, windows-vm-mount-boundary-test.sh, windows-vm-test.sh) with 100% pass rate.
  • Verified inside isolated Arch Linux LXC test container environment.

… privacy

Fixes omacom#11879

When dockurr/windows runs, its Samba service sets the setgid bit on the shared
folder (~/Windows), leaving it with mode 2700 instead of 0700. On Linux/BTRFS,
a numeric 'chmod 0700' does not clear an existing setgid bit. Consequently,
subsequent launches fail the [[ $shared_mode != 700 ]] safety check in
prepare_caller_mounts() and fail to start the VM.

1. In prepare_caller_mounts(), use 'chmod 00700' and explicitly strip setgid
   and setuid ('chmod ug-s') on pinned storage and shared descriptors.
2. In mounted_leaf_matches(), strip setgid/setuid on the caller-owned mount leaf
   before checking mode 700 to accommodate containers that mutate permissions.
3. In prepare_user_mount_sources(), also use 'chmod 00700' and 'chmod ug-s'.
4. Add regression test in windows-vm-mount-boundary-test.sh ensuring a setgid
   shared directory has setgid stripped and preserves 0700 mount privacy.
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: shared-folder setgid blocks relaunch after first run; KVM boot crash on Meteor Lake

1 participant