Why App Execution Aliases(AEA) won't run over SSH ?

[ghost]

launching a program from %program files%\windowsapps\AppFolder\app.exe over SSH , launches just fine.
but, launching from %localappdata%\microsoft\windowsapps\app.exe where AEAs reside; will throw ResourceUnavailable, system can not access the program error in a powershell session.

Why ? basically this dumbed down question has come from the need of running packaged desktop app over SSH.
tagging @DrusTheAxe as he has the most helpful answers here on MSIX related questions.

[DrusTheAxe]

launching a program from...

How did you 'launch' app.exe? CreateProcess()? ShellExecute()? AAM.ActivateApplication()? Absolute path'd exe on a command line?...

What's the user context when you 'launched' app.exe?

What version of Windows did you try this on?

What version of SSH (and whose SSH client+server)?

There's several possible explanations. Devil's in the details.

[ghost]

Thanks for responding.

not programmatically, Absolute path'd exe on a command line?... Yes
a Fulltrust command line calculator . I had to fiddle around permissions with WindowsApps\AppFolder\app.exe each of these node , giving 'NETWORK' group permission to each of these.
19043.1237 both for client and server.
Inbox openSSH, 8.1.p1, self testing.

Update : I've been searching around this and It seems AEAs are undocumented(?) special NTFS reparse points.
found how cygwin/cygwin@e6d1078 handles it, also it could entirely be a win32 OpenSSH program's reparse point handling issue.

[DrusTheAxe]

I had to fiddle around permissions with WindowsApps\AppFolder\app.exe each of these node

Ack! You don't want to do that. Fiddling with ACLs on package directories under WindowsApps can potentially be detected as "damage" and cause Windows to 'repair' the directory or even consider the package 'modified'/tampered/broken and unusable.

giving 'NETWORK' group permission to each of these.

That's interesting. Is openSSH an NTService running as NetworkService?

Update : I've been searching around this and It seems AEAs are undocumented(?) special NTFS reparse points.

AEA = ?

If you mean Extended Attributes yes they're documented, though I'm not sure if all the EAs used here are doc'd.

Reparse Points are a totally different concept. EAs are essentially key/value pairs for a filesystem entry (where 'value' could be a struct or other not-simple-data). Reparse Points are a dynamic evaluation mechanism. NTFS' symbolic links, junctions, HSM support and more are based on reparse points.

[riverar]

@mshaikhcool Can you provide some background as to why you're trying to do this? What's the end goal?

[ghost]

I had to fiddle around with that folder to check that if providing excutable absolute path works or not and it turned out that it works. yes, openssh server runs as NetworkService. AEA = App Execution Alias :] . I was able to find https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
IO_REPARSE_TAG_APPEXECLINK 0x8000001B | Used by Universal Windows Platform (UWP) packages to encode information that allows the application to be launched by CreateProcess. but, that's all there is.

@riverar the end goal here is to be able to run various MSIX packaged Cli tools over SSH(or WinRM) without providing absolute executable path (as MSI or raw exe's exposed to PATH work fine). MSIX packaged executables expose themselves(obviously via manifest and I think this is the preferred way for MSIX) to PATH via AEAs and the reason for all this.

End of the day, It's not necessary for me to know the underlying magic. Just the "How to get it work" part will be enough.
for the time being, I'm guessing it's the inbox openSSH program itself doesn't/can't handle those special reparse points.

[riverar]

Do you have repro steps? AEAs have executables in PATH already to support this scenario. That is, running [alias].exe in WSL works fine (e.g. $ spotify.exe)

Oh, you mentioned SSH not WSL.

I think we've reached the point where we very politely remind you this isn't relevant to the Windows App SDK and you should maybe post on Microsoft Q&A. I don't work for Microsoft though so feel free to ignore me on that point.

[ghost]

so I'm answering my own question.
If anyone who comes here thinking MSIX related questions are relevant here and wonders

why the heck the my MSIX packaged Cli tools won't run over SSH or WinRM ?

or the official windows package manager winget, just think for a second that a package manager itself can't be run over SSH :-)

I can confirm the answer to this is : the win32 openSSH team at https://github.com/PowerShell/Win32-OpenSSH has not yet found out how to handle those AEAs or they simply haven't bothered to fix it at all :-)
thank me later