PowerShell Permissions Helpers Are Not Compatible with PSH 2.0

[DarwinJS]

I originally commented in #721 under the heading "Installation Code Testing" that all PowerShell code should be tested on the target platforms of openssh, which I believe still includes Windows 7 / Server 2008 R2 RTM.

FYI - the code does appear to work for Nano.

FixHostFilePermissions, FixUserFilePermissions.ps1 and OpenSSHUtils.psm1 all have syntax or assumptions that are not compatible with PowerShell 2.0.

I fixed some, but I realized I don't have time to test if the scripts still actually perform their intended duties. I also noticed that some permissions do not seem to be updating after the below changes.

Here are the ones I know about:
FixHostFilePermissions, FixUserFilePermissions.ps1 = $psscriptroot was introduced in version 3.
Fixup - right under params block: If (!(Test-Path variable:PSScriptRoot)) {$PSScriptRoot = Split-Path -Parent $MyInvocation.MyCommand.Definition}

OpenSSHUtils.psm1: '-in' operator is not in PSH 2
Untested Fixup: change $abc -in $xyzarray to $xyzarray -icontains $abc (unsure if this is a full emulation of -in)

OpenSSHUtils.psm1: '.contains' method is not in PSH 2 (string objects?)
Untested Fixup: change $abc.contains($somedata) to $abc -contains $somedata (unsure if this is working)

FYI - I personally avoid testing with "powershell.exe -version 2" for compatibility with Win 7 / Server 2008 R2. There are just too many other differences.

If these scripts can be made compatible with PSH 2.0 and a pull request made - I will grab the code from the pull request and include it in the chocolatey package for 0.0.15.0 as an override of the files in the zip archives.

[bingbing8]

@DarwinJS Do you see any problem that user download WMF 5.1 on win7 machine? Here is WMF chocolatey package

[DarwinJS]

@bingbing8 - yes there are a lot of challenges with requiring PSH 5.1 (or any PSH upgrade) for something as small as this.

The below (plus more if I had time to think and write) are why I always maintain PowerShell 2.0 compatibility with any of my code that has to run on Win7/Server 2008 R2 RTM.

Compatibility:

• PowerShell Upgrades (especially from 2 to 5) require .NET upgrades - many machines have software stacks (especially servers) that are sensitive to the .NET version and cannot be moved forward. Many times the sensitivity is not in software under control of the machine owner - but rather is a sensitivity in some other dependency they require for their own or Off The Shelf software.
• There can be PowerShell version sensitivities in the main business software stack - especially if any of it has elected to internally use PowerShell for scripting or other types if integration with PowerShell
• PowerShell upgrades the entire WMF stack - which can also have similar challenges as those mentioned above - but for the management stack (software used to manage the node).

Logistics:

• Environment consistency - most shops will not want just the machines they install OpenSSH on to have a different version of PowerShell than everything else, so then the first software to require a new version begs the question of upgrading the entire fleet of similar purposed machines.
• getting an upgrade as fundamental as PowerShell 5.1 out is quite a logistical chore and a project in itself and rarely can large installations give 100% assurance the new version will make it out everywhere. For example 10% exceptions on 14,000 machines is 1400 - can't really follow up on why for every case.
• Even if the administrator of the target environment is willing and able to qualify whether they can upgrade PowerShell - it's a lot of work to get OpenSSH on the machine when simply using a different openssh client would not require this. In my opinion it is a huge burden to put in front of getting openssh on a machine - especially when resolvable by changing code syntax.

Putting My Money Where My Mouth Is:

• the above reasons are why I have maintained the Chocolatey PowerShell (full version) package to NEVER forcibly upgrade .NET to the required version - instead the package fails and makes the administrator responsible. Why? - because I don't want automatic dependency resolution to toast 500 servers under the care of an admin who elects to use my package to upgrade.
• it is also why the chocolatey installer for openssh uses WMIC instead of Get-wmiobject - the former is present on Nano and the later is not (at least not on RTM version)

[bingbing8]

@DarwinJS I will update the script work with ps 2.0

[bingbing8]

@DarwinJS the fix is checked in PowerShell/openssh-portable#160 and it works on ps2 on win7. Please let me know if you see any other issue

[DarwinJS]

@bingbing8 - thank you for this!

I have tested and I get some errors and the file permission does not change - please see the screenshot.

"ProtectedAdmin" is a custom user who is a regular admin - running elevated when the code runs.

[bingbing8]

@DarwinJS what os is this repro? this is due to a bug in default .net (localsystem is not allowed to be file owner, but icacls can set it) on the machine. I saw this on my win7 and workaround it like:
https://github.com/PowerShell/openssh-portable/blob/latestw_all/contrib/win32/openssh/OpenSSHUtils.psm1#L48-L66
Your machine may have different clr version from what I see.
Can you provide the output of these cmdlet? Thanks!
$PSVersionTable
[environment]::OSVersion

[DarwinJS]

This Windows 7 machine also has .NET 4.5.1 because Chocolatey requires it.