[release/v7.7.0-preview.1] Enable usage in AppContainers#27305
Conversation
Co-authored-by: Travis Plunk <travis.plunk@microsoft.com>
There was a problem hiding this comment.
Pull request overview
Backport of #27266 to release/v7.7.0-preview.1 to allow PowerShell to run correctly inside Windows AppContainers by avoiding false “drive missing” and “MyDocuments unavailable” detections caused by access-denied behavior.
Changes:
- Update fixed-drive root validation to treat
UnauthorizedAccessException(e.g., AppContainer access denied atC:\) as evidence the drive exists. - Use
Environment.SpecialFolderOption.DoNotVerifywhen resolvingMyDocumentsto avoid verification failures in sandboxed/redirected environments.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/System.Management.Automation/namespaces/FileSystemProvider.cs |
Introduces SafeDoesPathExist and uses it for fixed-drive root checks so fixed drives aren’t skipped when the root is access-denied. |
src/System.Management.Automation/engine/Modules/ModuleIntrinsics.cs |
Resolves MyDocuments using DoNotVerify to support sandboxed/redirected profile folder scenarios. |
| // In some scenarios (like AppContainers) direct access to the root directory may | ||
| // be prevented, but more specific paths may be accessible. | ||
| catch (UnauthorizedAccessException) | ||
| { | ||
| return true; |
There was a problem hiding this comment.
SafeDoesPathExist treats any UnauthorizedAccessException as “exists”. Because this helper is used by NewDrive, it changes behavior for access-denied non-root directories as well (not just drive roots/AppContainer). If you want to keep the change narrowly scoped, consider constraining the special-case to volume-root paths (where Path.GetPathRoot(...) matches the input) or clarifying the intended broader behavior in the helper’s comment/name.
1218a29
into
PowerShell:release/v7.7.0-preview.1
Backport of #27266 to release/v7.7.0-preview.1
Triggered by @jshigetomi on behalf of @SeeminglyScience
Original CL Label: CL-Engine
/cc @PowerShell/powershell-maintainers
Impact
REQUIRED: Choose either Tooling Impact or Customer Impact (or both). At least one checkbox must be selected.
Tooling Impact
Customer Impact
Fixes #27253. When PowerShell runs inside a Windows AppContainer, the root of the system drive (e.g. C:) is not directly accessible. The previous fixed-drive validation treated Directory.Exists returning false (due to access-denied) as evidence the drive was missing, which caused PowerShell to skip mounting all FileSystem PSDrives and effectively broke module loading and most cmdlets. This change treats UnauthorizedAccessException on the drive root as evidence the drive does exist, allowing PowerShell to operate normally in sandboxed AppContainer environments.
Regression
REQUIRED: Check exactly one box.
This is not a regression.
Testing
No new automated tests - AppContainer behavior cannot be exercised by the existing CI matrix without process-isolation infrastructure (the original PR was marked "N/A or can only be tested interactively"). The original fix was verified manually by the author by running PowerShell inside an AppContainer and confirming PSDrives mount and the personal module path resolves. Backport verification: cherry-pick applied cleanly with no conflicts against release/v7.7.0-preview.1; CI on the backport branch will exercise all existing FileSystemProvider and module-path tests to confirm no regression in the non-AppContainer fast path (where Directory.Exists still short-circuits).
Risk
REQUIRED: Check exactly one box.
Low risk. The change is narrowly scoped (28 additions / 3 deletions across 2 files) and behavior is strictly more permissive only on the previously-failing access-denied path: (1) SafeDoesPathExist is a new private static helper used solely for fixed-drive root validation in NewDrive and InitializeDefaultDrives - it preserves the existing Directory.Exists fast path and only widens behavior when that returns false; (2) Environment.SpecialFolderOption.DoNotVerify for MyDocuments is the documented .NET pattern for sandboxed/redirected profile scenarios and only changes behavior when the shell's verification step would have failed. Non-AppContainer behavior is unchanged. Two PowerShell maintainers (TravisEz13, asklar) approved the original PR.