-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Closed
Labels
Resolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or moreWG-Enginecore PowerShell engine, interpreter, and runtimecore PowerShell engine, interpreter, and runtime
Description
The tasks that I can think of are:
- maybe replace the singleton with static methods
- schema check
- 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.
- holding the config file in one process (e.g.
write
access ornone
share) will cause a new pwsh instance to crash at startup because it cannot access the config file and we don't deal with theIOException
.- 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.
- 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.
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.
Metadata
Metadata
Assignees
Labels
Resolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or moreWG-Enginecore PowerShell engine, interpreter, and runtimecore PowerShell engine, interpreter, and runtime