Powershell: Improve the configuration APIs in PSConfiguration.cs

Created on 7 Jan 2018  路  6Comments  路  Source: PowerShell/PowerShell

The tasks that I can think of are:

  1. maybe replace the singleton with static methods
  2. schema check
  3. synchronize updating the configuration file from multiple processes.

    • we currently have a read/write lock to protect updating/reading the config file. The lock doesn't help synchronize writing access from multiple processes.

  4. holding the config file in one process (e.g. write access or none share) will cause a new pwsh instance to crash at startup because it cannot access the config file and we don't deal with the IOException.

    • we could return default value when the config file is not accessible, but need to consider to not allow bypassing security settings because of that.



      • one option: have two sets of default values for security settings. One set is used when the config file doesn't exist or the security setting is not defined in the file; the other set is used when the file exists but not accessible, to enforce all security features that are configurable in the config file.



Repro step for 4:

First, run the following code to hold the config file of the current pwsh

$path = "path-to-powershell.config.json"
$mode = "Open"
$access = "Read"
$share = "None"

$file = [System.IO.File]::Open($path, $mode, $access, $share)

Then, start a new instance of the pwsh, and it will crash.

WG-Engine

Most helpful comment

@iSazonov @TravisEz13 GPO policy related discussion should happen in a new issue. This issue is for improving the APIs for reading settings from powershell.config.json file. The precedence order of policy related settings is another layer on top of the configuration APIs, not the configuration APIs themselves.

All 6 comments

We could make public API to enable developers to work consistently with config files.

It seems currently we read config option step-by-step by demand. I think re-read all config file(s) in one step and cache it is more optimal.

Suggestions:

  • use Windows PowerShell GPO by default to not allow users ignore security and Enterprise policies for PowerShell
  • add new GPO branch for PowerShell Core to allow Enterprises configure Windows PowerShell and PowerShell Core separately.
  • use GPO policies (Software\Policies\Microsoft\Windows\PowerShell) and GPO config options (Software\Microsoft\Windows\PowerShell)
  • we want #5804 RegisterGPNotification we should do the same for config files too.

Configuration priority:

Windows | Unix
-| -
GPO Computer Policy for PowerShell Core | File
GPO Computer Policy for Windows PowerShell | -
File Computer-Wide Version | File Computer-Wide Version
GPO User Policy | ?
File Local Version | File Local Version
File User-Wide (AppData) | File User-Wide
GPO Computer Config | ?
GPO User Config | ?

GPO Computer Policy for Windows PowerShell is not considered when in PS Core as this policy is for a separate product. If we want to honor policy for Windows PowerShell, we should not introduce a policy for PowerShell Core.

@iSazonov @TravisEz13 GPO policy related discussion should happen in a new issue. This issue is for improving the APIs for reading settings from powershell.config.json file. The precedence order of policy related settings is another layer on top of the configuration APIs, not the configuration APIs themselves.

Was this page helpful?
0 / 5 - 0 ratings