jborean93
commented
3 years ago This is going to be tricky but after testing this myself I have found a way. To understand the solution we first need to see how the fork is being loaded. There are 2 libraries in this fork:
psrpclient- Entrypoint from PowerShell, wrapsmito make it match the Win32 API for WSMan so PowerShell stays consistentmi- The code that implements the WSMan stack, linked topsrpclient
PowerShell itself hardcodes the DllImport path for the WSMan calls to libpsrpclient on Linux https://github.com/PowerShell/PowerShell/blob/2784add414393b0ecab798055cfbac0d363c1c1e/src/System.Management.Automation/engine/remoting/fanin/WSManNativeAPI.cs#L2339 so we are at the mercy of how .NET/dlopen resolves that library. Normally it's going to load libpsrpclient.so that is in the PowerShell directory which it itself then loads libmi.so in the same dir. So just replacing the files is the simplest way to get this working and it will automatically just happen.
Unfortunately in this scenario we don't have access to modify the files in the PowerShell directory so we need to somehow tell .NET that when it comes to loading psrpclient it should use a custom path instead. To do this we need to add a custom import resolver for the PowerShell assembly which can modify the path used.
This is the code you can use to set this up:
# Defaults to installing in the CurrentUser, just need to run once
Install-Module -Name PSWSMan -Force
# Need to run each time the shell is opened, no idea if there's a profile this can be set to
Add-Type -TypeDefinition @'
using System;
using System.Collections.Generic;
using System.Reflection;
using System.Runtime.InteropServices;
namespace CloudShell
{
public static class MI
{
public static Dictionary<string, string> DllMap = new Dictionary<string, string>();
public static IntPtr ImportResolver(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
if (DllMap.ContainsKey(libraryName))
libraryName = DllMap[libraryName];
return NativeLibrary.Load(libraryName, assembly, searchPath);
}
}
}
'@
$libbase = Join-Path (Import-Module -Name PSWSMan -PassThru).ModuleBase lib debian10
[CloudShell.MI]::DllMap['libpsrpclient'] = Join-Path $libBase libpsrpclient.so
[Runtime.InteropServices.NativeLibrary]::SetDllImportResolver([PSObject].Assembly, [CloudShell.MI]::ImportResolver)What this does is it gets the path to libpsrpclient.so for the distribution we are running on (this case being Debian 10 based on /etc/os-release). Adds it to the static field DllMap which the new import resolver for PowerShell will use to modify the import path whenever libpsrpclient is being imported. The libmi module should just be loaded by dlopen() automatically but this happens outside of .NET so we can't really control that functionality.
A few things to note:
- This will only affect anything in the PowerShell assembly loading this library
Get-WSManVersionfromPSWSManwill not use this new path and will thus report that it isn't installed- There's no easy way to fix this as the assembly we need set it to is dynamically created
- Ultimately it's off little consequence as we only really care about what PowerShell loads
- This needs to be run everytime the shell starts up
- I assume there's a profile that this can be added to but I just didn't have time to look into it further
SetDllImportResolveronly works when there isn't already a custom resolver- This is current the case for PowerShell but I can't gurantee they won't add their own in the future breaking this setup
Hopefully this gets you moving forward, I tried a few other attempts like calling dlopen() manually to cache the file but that never worked. In the end this route does seem to work for me when testing it so I assume it should also work for you. Good luck!
janegilring
SUMMARY
Azure Cloud Shell is based on a Linux container image running Ubuntu 16.04 - without any sudo permissions.
Are there any way of leveraging this custom OMI module without sudo access? For example by loading it from the user's home directory.
OS / ENVIRONMENT