You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
virtiofs: impersonate Windows users for host filesystem access - #4876
This PR adds per-user access to Windows shares through virtiofs. Host filesystem access currently uses the VM service process token, which may have different permissions from the user whose files are being shared.
Callers can provide a Windows token handle duplicated into the VM service process through the virtiofs RPC configuration. OpenVMM owns a duplicate and impersonates it when opening the share and handling each FUSE request, then reverts to the process identity afterward. The token is kept with the FUSE session. Omitting the token or passing zero preserves the existing behavior.
Invalid tokens fail device creation, and requests return an I/O error if impersonation fails rather than falling back to the process token. Windows regression tests check that successful and failing FUSE requests run under a restricted token and leave no thread token afterward.
The reason will be displayed to describe this comment to others. Learn more.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Adds Windows user-token impersonation support for virtio-fs host filesystem access, enabling per-user permissions rather than always using the VM service process token.
Changes:
Introduces VirtioFsSession wrapper to optionally impersonate a Windows user token per FUSE request.
Extends virtio-fs resource/config plumbing to carry optional Windows token handle and duplicate it into OpenVMM.
Refactors device construction to use a VirtioFsDeviceOptions struct and adds parsing/validation in the virtiofs resolver.
File
Description
vmm_tests/vmm_tests/tests/tests/ttrpc.rs
Updates virtio-fs test configs to populate the new windows_options field.
vm/devices/virtio/virtiofs/src/virtio.rs
Refactors device construction around options and routes requests through VirtioFsSession for optional impersonation.
vm/devices/virtio/virtiofs/src/session.rs
Adds a session wrapper that impersonates a Windows token during dispatch and returns EIO on impersonation failure.
vm/devices/virtio/virtiofs/src/resolver.rs
Adds structured parsing/validation and Windows-specific token duplication/impersonated open behavior.
vm/devices/virtio/virtiofs/src/lib.rs
Wires in new impersonation (Windows) and session modules.
Add regression test for Windows impersonation failure
vm/devices/virtio/virtiofs/src/session.rs:51
Please add a Windows regression for impersonation failure, using an owned non-token handle, and assert that dispatch returns -EIO, never invokes the filesystem, and leaves no thread token. The added dispatch test only exercises a filesystem EACCES after impersonation succeeds, so it would still pass if this failure path regressed to dispatching with the process identity.
The reason will be displayed to describe this comment to others. Learn more.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Human assessment is needed because the Windows regression test does not exercise impersonation failure, leaving fail-closed behavior against dispatch under the process identity unverified.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Missing Windows regression tests leave impersonation-failure handling and token-scoped share opening unverified, including protection against process-identity fallback and thread-token cleanup.
Duplicate the caller's token while resolving HostFs, retain it with the FUSE session, and impersonate it for each dispatch. Revert afterward and cover successful and failing dispatches with a restricted-token regression test.
Split user impersonation from PR microsoft#4706 without DAX remapping or backend-option changes. Keep resource and protobuf field numbers compatible with the independent DAX branch.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Keep common HostFs parsing and resource resolution together, with token parsing and impersonation in one platform-specific implementation block. Preserve existing validation and token ownership, and cover rejection of Windows-only options on other hosts.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Extract RevertToSelfGuard into pal::windows::security and reuse it for virtiofs requests and sparse-mmap privilege adjustment. Keep impersonation thread-bound and preserve fail-fast cleanup behavior.
Share root-path validation between HostFs and SectionFs.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
main replaced the cfg-if crate with the standard cfg_select! macro (microsoft#4883).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Windows regression tests do not cover fail-closed dispatch when impersonation fails or verify the identity used to open the share, leaving security-sensitive behavior unprotected against regressions.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The Windows filesystem identity boundary and cross-process handle transfer require human security review and Windows runtime testing to validate ACL enforcement, token lifetime, and impersonation cleanup.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Windows impersonation and client-supplied handle registration alter security and cross-process ownership boundaries, requiring security-owner review and native Windows validation beyond the available static inspection.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Windows impersonation and cross-process token transfer alter an access-control boundary, requiring human security review and native Windows validation that was unavailable.
No open issues 🎉
Review effort: Balanced
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds per-user access to Windows shares through virtiofs. Host filesystem access currently uses the VM service process token, which may have different permissions from the user whose files are being shared.
Callers can provide a Windows token handle duplicated into the VM service process through the virtiofs RPC configuration. OpenVMM owns a duplicate and impersonates it when opening the share and handling each FUSE request, then reverts to the process identity afterward. The token is kept with the FUSE session. Omitting the token or passing zero preserves the existing behavior.
Invalid tokens fail device creation, and requests return an I/O error if impersonation fails rather than falling back to the process token. Windows regression tests check that successful and failing FUSE requests run under a restricted token and leave no thread token afterward.