So you’re trying to automate Windows Subsystem for Linux.
(i’m sorry) – it goes without saying that this is super beta software. expect pain and rough edges. if you have alternatives, explore them until this is a more well-cooked shippable thingy.
Maybe things are going well though. You’ve got a script that can execute under a user to actually get it instantiated via
and it succeeds!
Now you have another problem though. You can’t just log in via SSH or PowerShell Remoting and invoke
… boo! You get returned 0x80070005 unless you’re totally interactive on the local Desktop with a local user.
That’s not cool though, we want to reach these things remotely and invoke things in an automation-friendly way. As it turns out, there are a couple of things preventing you from achieving this. Primarily:
- Local launch and activation permissions on the Linux Subsystem / LXSS (as it’s referenced internally) DCOM configuration object.
- Registry permissions which prevent you from modifying the above.
Let’s start with the registry permissions which are required to touch the items of the first bullet.
as an Administrator
- Traverse into:
- Right-click on
- Open Permissions > Advanced > Change link to modify Owner
- Change to “Administrators”, check “Replace owner on subcontainers and objects”
- Give “Full Control” to Administrators group
- Go back and dig into:
- Complete the same steps as above, instead modifying this folder:
Now for the DCOM configuration, open Component Services from the start menu.
- Expand into Component Services > Computers > My Computer > DCOM Config, and set list view as shown in the screenshot:
- No, this list is not searchable. You can quickly jump down the index if you have fast fingers and can start typing the GUID that corresponds to the AppID we want to change,
. Right click and open Properties, at which point you should be able to “Edit” the Launch and Activation Permissions. If these are gray, you need to go back to the earlier steps and ensure you followed them properly. This is what those permissions adjustments allow us to do.
- “Add” Administrators to the security ACL table, and select Local Launch and Local Activation for this group. I opted for Administrators rather than a specific user so that scripting this it can be agnostic of any specific user configuration, and also retain some form of secure design by only allowing those who are already in the Administrators group to be able to touch these perms, and also invoke the LXSS components. This is important because there are serious security implications when inside the LXSS environment where most permissions don’t apply and you can break stuff really fast.
Now that you’ve completed these steps, you should immediately be able to use Windows Subsystem for Linux in places previously not accessible, such as Win32-OpenSSH.
There’s a good chance your edits could be reverted if an update occurs that touches or otherwise lays down new configuration on top of what you previously modified. It’s a good idea to script this and perhaps run it through Ansible or a scheduled task (yuck) periodically. I’ve done some work to discover the PowerShell necessary to modify these ACLs, and will update this post soon or perhaps create a new one when it’s ready.
For now, you can find that bleeding edge hackery in my Gists.