Description

Dongbo Wang (daxian-dbw)

opened on Jan 6, 2018

Issue body actions

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.

Activity

1. Dongbo Wang (daxian-dbw)

   added

   WG-Enginecore PowerShell engine, interpreter, and runtimecore PowerShell engine, interpreter, and runtime

   on Jan 6, 2018
2. iSazonov commented on Jan 7, 2018

   

   Ilya (iSazonov)

   on Jan 7, 2018

   Collaborator

   More actions

   We could make public API to enable developers to work consistently with config files.
3. iSazonov commented on Jan 7, 2018

   

   Ilya (iSazonov)

   on Jan 7, 2018

   Collaborator

   More actions

   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.
4. iSazonov commented on Jan 7, 2018

   

   Ilya (iSazonov)

   on Jan 7, 2018

   Collaborator

   More actions

   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 The static cache for group policy settings should be cleared when GP settings change #5804 RegisterGPNotification we should do the same for config files too.

   Reacted by Alex Verboon
5. iSazonov commented on Jan 7, 2018

   

   Ilya (iSazonov)

   on Jan 7, 2018

   Collaborator

   More actions

   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	?
6. TravisEz13 commented on Jan 8, 2018

   

   Travis Plunk (TravisEz13)

   on Jan 8, 2018

   Member

   More actions

   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.

   Reacted by Mark Kraus
7. daxian-dbw commented on Jan 8, 2018

   

   Dongbo Wang (daxian-dbw)

   on Jan 8, 2018

   MemberAuthor

   More actions

   Ilya (@iSazonov) Travis Plunk (@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.

   Reacted by Travis Plunk and Alex Verboon
8. microsoft-github-policy-service commented on Nov 16, 2023

   

   microsoft-github-policy-serviceBot

   on Nov 16, 2023 – with Microsoft GitHub Policy Service

   Contributor

   More actions

   This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
9. microsoft-github-policy-service commented on Nov 16, 2023

   

   microsoft-github-policy-serviceBot

   on Nov 16, 2023 – with Microsoft GitHub Policy Service

   Contributor

   More actions

   This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
10. microsoft-github-policy-service

    added

    Resolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or more

    on Nov 16, 2023
11. microsoft-github-policy-service commented on Nov 16, 2023

    

    microsoft-github-policy-serviceBot

    on Nov 16, 2023 – with Microsoft GitHub Policy Service

    Contributor

    More actions

    This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
12. microsoft-github-policy-service commented on Nov 23, 2023

    

    microsoft-github-policy-serviceBot

    on Nov 23, 2023 – with Microsoft GitHub Policy Service

    Contributor

    More actions

    This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.
13. microsoft-github-policy-service

    closed this as completedon Nov 23, 2023

Issue actions