Conversation
…ation Co-authored-by: kilasuit <[email protected]>
Co-authored-by: kilasuit <[email protected]>
There was a problem hiding this comment.
Pull request overview
Adds a new elevation check to PowerShell by introducing a $IsElevated built-in variable and a Test-Elevated cmdlet, with accompanying Pester coverage.
Changes:
- Introduces
$IsElevatedas a built-in, read-only, all-scope variable populated fromPlatform.IsElevated. - Adds
Platform.IsElevatedwith OS-specific implementations (Windows admin token check; Unixgeteuid()==0). - Adds
Test-Elevatedcmdlet and new Pester tests validating existence/type/value consistency.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| test/powershell/Modules/Microsoft.PowerShell.Management/Test-Elevated.Tests.ps1 | Adds Pester tests for $IsElevated and Test-Elevated. |
| src/System.Management.Automation/engine/SpecialVariables.cs | Adds IsElevated constant and VariablePath entry. |
| src/System.Management.Automation/engine/Interop/Unix/GetEuid.cs | Adds Unix interop for geteuid to determine root/elevated state. |
| src/System.Management.Automation/engine/InitialSessionState.cs | Registers $IsElevated as a built-in variable at runspace initialization. |
| src/System.Management.Automation/CoreCLR/CorePsPlatform.cs | Implements Platform.IsElevated with caching. |
| src/Microsoft.PowerShell.Commands.Management/commands/management/TestElevatedCommand.cs | Adds Test-Elevated cmdlet returning Platform.IsElevated. |
test/powershell/Modules/Microsoft.PowerShell.Management/Test-Elevated.Tests.ps1
Show resolved
Hide resolved
src/Microsoft.PowerShell.Commands.Management/commands/management/TestElevatedCommand.cs
Outdated
Show resolved
Hide resolved
kilasuit
added
the
CL-Engine
|
Although we always want to have something like this, in general it is very controversial. For example, in a corporate environment, it is increasingly preferred to create limited accounts with only sufficient rights to perform a specific task and at the same time block the rights of traditional accounts with elevated rights. |
|
@iSazonov I get that & the overall end goal would be to in future allow a workflow where each part of a pipeline could require elevation to a particular user that has that access for only that small section of the executed command like in cross tenant management situations I'm not massively fussed if this ends up getting merged or not but it was a decent learning experience either way |
src/System.Management.Automation/engine/Interop/Unix/GetEuid.cs
Outdated
Show resolved
Hide resolved
|
I think this is ready for a review. Only comment I think I have based on having a look at @jshigetomi PR for PSContentPath is do I need to add items into SessionState.cs where I have it InitalSessionState.cs I don't think I do but wanted to double check. |
SeeminglyScience
added
CL-General
PR Summary
Adds infrastructure that allows users to test in a PowerShelly way if they are running a session with elevated privileges
PR Context
We have lots of samples of code out there checking for this, like this Test-IsAdmin function in this PR
This should be something that I feel we should have built-in & in a PowerShelly way allowing both checking via a new cmdlet
Test-Elevated& checking via a new automatic variable$IsElevatedThis I feel could help in the future with enabling shipping both scripts & modules with cmdlets that require elevated privileges to be able to do certain tasks, but may still be able to complete the majority of authors intent when not elevated as started in this discussion
This starts the process for enabling cmdlet level elevation in a session that started non-elevated and only a single part of a command/script requires elevation, whilst also further in future enabling a user to control via custom session configuration, what commands should prompt for elevation, how often they should prompt, and if there are any ones for that session can be allowed to elevate with no prompt.
This would allow in future for a cmdlet's ParameterSet that includes
-Forceto only be run if the author of that cmdlet explicitly checks if the session is elevated & then ask them if it is not, if they want to elevate for just this one cmdlet's execution.This, would in future allow for checking if the user is in any other built in role in Windows other than Administrator, optionally enabling a check for differing types of elevated privilages that may not be system wide, like Hyper-V Administrator group & other groups that may get added that have different security needs above a standard user account.
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header