How to check programatically if app runs with runFullTrust capability or not?

[MartyIX]

MAUI app templates defines that WinUI apps runs with the runFullTrust capability. However, presumably, users can change it if they want.

I would like to find out, if the runFullTrust capability is defined or not on runtime. It would help me skip this costly part in the PR of mine (dotnet/maui#23047) instead of just deleting that code entirely.

Does anybody know how to find it out?

[DarranRowe]

It isn't the runFullTrust capability, it is whether or not the AppContainer is active.
An example of what I mean is that runFullTrust controls whether the FullTrustProcessLauncher runtime class can be used. This is independent of how the application runs.

What determines how the application itself runs is the Application element of the manifest. If the package is targetted at older versions of Windows 10 (< 19041), then it is the EntryPoint attribute that controls things. If the entry point is a runtime class name, then this is a UWP application. If the entry point is windows.fullTrustApplication (case insensitive), then it is a medium IL application that runs outside of an AppContainer. If the entry point is windows.partialTrustApplication (case insensitive), then it is a low IL application that runs inside of an AppContainer.
If it is targetted at newer versions of Windows (>= 19041), then the manifest can also contain uap10:RuntimeBehaviour and uap10:TrustLevel attributes. These are able to replace the entry point attribute for desktop applications, and it is then the uap10:TrustLevel that determines if the application runs in an AppContainer.

Anyway, things can get rather messy. First, you cannot check a single value to determine things fully. There are some shortcuts, like using Windows.UI.Core.CoreWindow.GetForCurrentThread on the main thread. This is going to fail in a desktop application, so if it succeeds then you know that you are working in a UWP environment.
However, checking if an application is in a package doesn't say anything about it running in an AppContainer, and checking if an application is in an AppContainer doesn't say anything about it running in a package. Checking for the package is easy, you can use the WinRT API, Windows.ApplicationModel.Package.Current will fail in an unpackaged application or give the package information in a packaged application. You can also use the GetCurrentPackageInfo Windows API function. Again, this will fail in an unpackaged application and supply valid information in a packaged application.
Checking for the AppContainer itself is more annoying. The only place that I know of where you can find this information is in the process' security token. This means calling GetTokenInformation with the TOKEN_INFORMATION_CLASS::TokenIsAppContainer value. But this doesn't imply that the application is packaged since you can always use CreateProcess with the extended startup information, and adding a PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES attribute, thus allowing you to place an unpackaged application inside an AppContainer.
Depending on what you want to do, you may have to fall back to reading the package manifest file.

For your particular case, I think checking for the presence of the AppContainer should be enough.

[YourOrdinaryCat]

Not just because of runFullTrust, but also because of the general lack of information on this topic, you can check for capability access through AppCapability from 1903 onwards. I just tried checking for runFullTrust and broadFileSystemAccess on an unpackaged WinUI 3 app, and it actually says the capability access status is Allowed for both. I don't have time to try out every scenario proposed by @DarranRowe, but I suppose for this specific use case, checking for broadFileSystemAccess should be enough.

Example code:

using Windows.Security.Authorization.AppCapabilityAccess;

namespace Foo;

public static class Bar
{
    public static AppCapabilityAccessStatus CheckRFT()
    {
        var ac = AppCapability.Create("runFullTrust");
        return ac.CheckAccess();
    }

    public static AppCapabilityAccessStatus CheckBFSA()
    {
        var ac = AppCapability.Create("broadFileSystemAccess");
        return ac.CheckAccess();
    }
}

[DarranRowe]

The situation is actually much more annoyingly messy and complex than even I implied with my post. To illustrate what I mean, consider the following use of a FileOpenPicker.

    winrt::Windows::Foundation::IAsyncAction MainWindow::Click_Click(winrt::IInspectable const &, winrt::RoutedEventArgs const &)
    {
        auto picker = Windows::Storage::Pickers::FileOpenPicker();
        auto picker_iiww = picker.as<IInitializeWithWindow>();
        _ASSERTE(SUCCEEDED(picker_iiww->Initialize(GetWindowFromWindowId(AppWindow().Id()))));

        picker_iiww = nullptr;

        picker.FileTypeFilter().Append(L".txt");

        auto picker_result = co_await picker.PickSingleFileAsync();

        Content().Text(picker_result.Name());
        
        co_return;
    }

If you use this in a packaged application that is full trust, you get:

2024-06-16.16-28-47.mp4

However, if you use this in a packaged application that is partial trust (running in an AppContainer) then you get:

2024-06-16.16-29-52.mp4

What seems to be happening is that the code for setting the HWND in the IInitializeWithWindow::Initialize call is checking if the application is running in an AppContainer. If it is running in an AppContainer then it will refuse to change the root window, possibly assuming that it is a UWP application. So technically this is all currently a moot point due to the entire system not working in a desktop application.

For the BFA capability and the check for it, this makes sense because a full trust/medium il process doesn't have the AppContainer capabilities getting in the way. You should also find that a packaged application running as full trust will also have the BFA capability. But the issue checking just for this is the same issue as just checking for the presence of an AppContainer, that is, it potentially adds too many files to the future access list. To give an example of what I mean, suppose my packaged application has the documentsLibrary capability but no broadFileSystemAccess capability. If you use the picker to select a file in the documents library (assuming the previous issue doesn't exist) then only checking for BFA would mean that the item in documents would be added to the future access list when it doesn't need to be. I won't argue if you want to point out that checking for BFA catches more though.
Ah well.

[YourOrdinaryCat]

The only way I can think of to ensure there's no access to the file prior to adding it to the FutureAccessList, is trying to get it from its path, which would be even more expensive because it needs to go through StorageFile (FromApp APIs don't work for e.g. OneDrive paths). And well, the picker doesn't even work properly under partial trust yet as you mentioned, so this would only be useful under UWP which I'm not sure is even supported by MAUI.

I have to wonder why the files are added to the FutureAccessList in the first place - I'm not familiar with MAUI, but do other platforms persist access to the file through its path after the user picks it? As long as the StorageFile instance is kept alive, it should be fine I think.