How can I elevate Powershell while keeping the current working directory AND maintain all parameters passed to the script?

by

Note: On 15 Nov 2021 a bug was fixed in the code below in order to make it work properly with advanced scripts – see this answer for details.

The closest you can get to a robust, cross-platform self-elevating script solution that supports:

  • both positional (unnamed) and named arguments
    • while preserving type fidelity within the constraints of PowerShell’s serialization (see this answer)
  • preserving the caller’s working directory.
  • On Unix-like platforms only: synchronous, same-window execution with exit-code reporting (via the standard sudo utility).

is the following monstrosity (I certainly wish this were easier):

  • Note:

    • For (relative) brevity, I’ve omitted your Test-IsUacEnabled test, and simplified the test for whether the current session is already elevated to [bool] (net.exe session 2>$null)

    • You can drop everything between # --- BEGIN: Helper function for self-elevation. and # --- END: Helper function for self-elevation. into any script to make it self-elevating.

      • If you find yourself in repeated need of self-elevation, in different scripts, you can copy the code into your $PROFILE file or – better suited to wider distribution – convert the dynamic (in-memory) module used below (via New-Module) into a regular persisted module that your scripts can (auto-)load. With the Ensure-Elevated function available available via an auto-loading module, all you need in a given script is to call Ensure-Elevated, without arguments (or with -Verbose for verbose output).
# Sample script parameter declarations.
# Note: Since there is no [CmdletBinding()] attribute and no [Parameter()] attributes,
#       the script also accepts *unbound* arguments.
param(
  [object] $First,
  [int] $Second,
  [array] $Third
)

# --- BEGIN: Helper function for self-elevation.
# Define a dynamic (in-memory) module that exports a single function, Ensure-Elevated.
# Note: 
#  * In real life you would put this function in a regular, persisted module.
#  * Technically, 'Ensure' is not an approved verb, but it seems like the best fit.
$null = New-Module -Name "SelfElevation_$PID" -ScriptBlock {  
  function Ensure-Elevated {

    [CmdletBinding()]
    param()

    $isWin = $env:OS -eq 'Windows_NT'

    # Simply return, if already elevated.
    if (($isWin -and (net.exe session 2>$null)) -or (-not $isWin -and 0 -eq (id -u))) { 
      Write-Verbose "(Now) running as $(("superuser", "admin")[$isWin])."
      return 
    }

    # Get the relevant variable values from the calling script's scope.
    $scriptPath = $PSCmdlet.GetVariableValue('PSCommandPath')
    $scriptBoundParameters = $PSCmdlet.GetVariableValue('PSBoundParameters')
    $scriptArgs = $PSCmdlet.GetVariableValue('args')

    Write-Verbose ("This script, `"$scriptPath`", requires " + ("superuser privileges, ", "admin privileges, ")[$isWin] + ("re-invoking with sudo...", "re-invoking in a new window with elevation...")[$isWin])

    # Note: 
    #   * On Windows, the script invariably runs in a *new window*, and by design we let it run asynchronously, in a stay-open session.
    #   * On Unix, sudo runs in the *same window, synchronously*, and we return to the calling shell when the script exits.
    #   * -inputFormat xml -outputFormat xml are NOT used:
    #      * The use of -encodedArguments *implies* CLIXML serialization of the arguments; -inputFormat xml presumably only relates to *stdin* input.
    #      * On Unix, the CLIXML output created by -ouputFormat xml is not recognized by the calling PowerShell instance and passed through as text.
    #   * On Windows, the elevated session's working dir. is set to the same as the caller's (happens by default on Unix, and also in PS Core on Windows - but not in *WinPS*)
    
    # Determine the full path of the PowerShell executable running this session.
    # Note: The (obsolescent) ISE doesn't support the same CLI parameters as powershell.exe, so we use the latter.
    $psExe = (Get-Process -Id $PID).Path -replace '_ise(?=\.exe$)'

    if (0 -ne ($scriptBoundParameters.Count + $scriptArgs.Count)) {
      # ARGUMENTS WERE PASSED, so the CLI must be called with -encodedCommand and -encodedArguments, for robustness.

      # !! To work around a bug in the deserialization of [switch] instances, replace them with Boolean values.
      foreach ($key in @($scriptBoundParameters.Keys)) {
        if (($val = $scriptBoundParameters[$key]) -is [switch]) { $null = $scriptBoundParameters.Remove($key); $null = $scriptBoundParameters.Add($key, $val.IsPresent) }
      }
      # Note: If the enclosing script is non-advanced, *both*
      #       $scriptBoundParameters and $scriptArgs may be present.
      #       !! Be sure to pass @() when $args is $null (advanced script), otherwise a scalar $null will be passed on reinvocation.
      #       Use the same serialization depth as the remoting infrastructure (1).
      $serializedArgs = [System.Management.Automation.PSSerializer]::Serialize(($scriptBoundParameters, (@(), $scriptArgs)[$null -ne $scriptArgs]), 1)

      # The command that receives the (deserialized) arguments.
      # Note: Since the new window running the elevated session must remain open, we do *not* append `exit $LASTEXITCODE`, unlike on Unix.
      $cmd = 'param($bound, $positional) Set-Location "{0}"; & "{1}" @bound @positional' -f (Get-Location -PSProvider FileSystem).ProviderPath, $scriptPath
      if ($isWin) {
        Start-Process -Verb RunAs $psExe ('-noexit -encodedCommand {0} -encodedArguments {1}' -f [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($cmd)), [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($serializedArgs)))
      }
      else {
        sudo $psExe -encodedCommand ([Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($cmd))) -encodedArguments ([Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($serializedArgs)))
      }

    }
    else {
      # NO ARGUMENTS were passed - simple reinvocation of the script with -c (-Command) is sufficient.
      # Note: While -f (-File) would normally be sufficient, it leaves $args undefined, which could cause the calling script to break.
      # Also, on WinPS we must set the working dir.

      if ($isWin) {
        Start-Process -Verb RunAs $psExe ('-noexit -c Set-Location "{0}"; & "{1}"' -f (Get-Location -PSProvider FileSystem).ProviderPath, $scriptPath)
      }
      else {
        # Note: On Unix, the working directory is always automatically inherited.
        sudo $psExe -c "& `"$scriptPath`"; exit $LASTEXITCODE"
      }

    }

    # EXIT after reinvocation, passing the exit code through, if possible:
    # On Windows, since Start-Process was invoked asynchronously, all we can report is whether *it* failed on invocation.
    exit ($LASTEXITCODE, (1, 0)[$?])[$isWin]

  }

}
# --- END: Helper function for self-elevation.

"Current location: $($PWD.ProviderPath)"

# Call the self-elevation helper function:
#  * If this session is already elevated, the call is a no-op and execution continues,
#    in the current console window.
#  * Otherwise, the function exits the script and re-invokes it with elevation,
#    passing all arguments through and preserving the working directory.
#  * On Windows:
#     * UAC will prompt for confirmation / adming credentials every time.
#     * Of technical necessity, the elevated session runs in a *new* console window,
#       asynchronously, and the window running the elevated session remains open.
#       Note: The new window is a regular *console window*, irrespective of the 
#             environment you're calling from (including Windows Terminal, VSCode,
#             or the (obsolescent) ISE).
#     * Due to running asynchronously in a new window, the calling session won't know 
#       the elevated script call's exit code.
#  * On Unix:
#     * The `sudo` utility used for elevation will prompt for a password,
#       and by default remembers it for 5 minutes for repeat invocations. 
#     * The elevated script runs in the *current* window, *synchronously*,
#       and $LASTEXITCODE reflects the elevated script's exit code.
#       That is, the elevated script runs to completion and only then
#       returns control to the non-elevated caller.
#       Note that $LASTEXITCODE is only meaningful if the elevated script
#       sets its intentionally, via `exit $n`.
# Omit -Verbose to suppress verbose output.
Ensure-Elevated -Verbose

# For illustration:
# Print the arguments received in diagnostic form.
Write-Verbose -Verbose '== Arguments received:'
[PSCustomObject] @{
  PSBoundParameters = $PSBoundParameters.GetEnumerator() | Select-Object Key, Value, @{ n='Type'; e={ $_.Value.GetType().Name } } | Out-String
  # Only applies to non-advanced scripts
  Args = $args | ForEach-Object { [pscustomobject] @{ Value = $_; Type = $_.GetType().Name } } | Out-String
  CurrentLocation = $PWD.ProviderPath
} | Format-List

Sample call:

If you save the above code to file script.ps1 and invoke it as follows:

./script.ps1 -First (get-date) -Third  ('foo', 'bar') -Second 42  @{ unbound=1 } 'last unbound'

you’ll see the following:

  • In the non-elevated session, which triggers the UAC / sudo password prompt (Windows example):

     Current location: C:\Users\jdoe\sample
 VERBOSE: This script, "C:\Users\jdoe\sample\script.ps1", requires admin privileges, re-invoking in a new window with elevation...

  • In the elevated session (which on Unix runs transiently in the same window):

     VERBOSE: (Now) running as admin.
 VERBOSE: == Arguments received:

 PSBoundParameters : 
                     Key    Value                  Type
                    ---    -----                  ----
                     First  10/30/2021 12:30:08 PM DateTime
                     Third  {foo, bar}             Object[]
                     Second 42                     Int32


 Args              : 
                     Value        Type
                     -----        ----
                     {unbound}    Hashtable
                     last unbound String

 CurrentLocation   : C:\Users\jdoe\sample

More Related Contents:

  1. Need to extract value of attribute from xml from Command promt [closed]
  2. How do I write the value of a single property of a object?
  3. PowerShell, formatting values in another culture
  4. How can I store output from Format-Table for later use
  5. How can I use powershell to run through an installer?
  6. How do I concatenate strings and variables in PowerShell?
  7. PowerShell and process exit codes
  8. How to load assemblies in PowerShell?
  9. Convert a secure string to plain text
  10. How to exit from ForEach-Object in PowerShell
  11. PowerShell – Decode System.Security.SecureString to readable password
  12. Convert a string to datetime in PowerShell
  13. What does $_ mean in PowerShell?
  14. How to pass credentials to the Send-MailMessage command for sending emails
  15. PowerShell: Store Entire Text File Contents in Variable
  16. How to get Powershell Invoke-Restmethod to return body of http 500 code response
  17. How to normalize a path in PowerShell?
  18. How to create new clone instance of PSObject object
  19. Arrays and -contains – test for substrings in the elements of an array
  20. How to create a shortcut using PowerShell
  21. Try/catch does not seem to have an effect
  22. How to run an installation in /silent mode with adjusted settings
  23. PowerShell string interpolation syntax
  24. Get target of shortcut (.lnk) file with powershell
  25. Is there an alternative to GUID when using msiexec to uninstall an application?
  26. Can’t install nuget package because of “Failed to initialize the PowerShell host”
  27. What security setting is preventing Remote PowerShell 2.0 from accessing UNC paths
  28. PowerShell Capture Write-Host output
  29. start remote process within the context
  30. dotnet ef scaffold Unrecognized option ‘-t firstTable -t secondTable’ – pass arguments stored in a string

Leave a Comment