Can you duplicate a file handle from a mediumIL process into an AppContainer process?

[wjk]

Can I call DuplicateHandle() successfully (returning the duplicated handle to the AppContainer app over an IPC mechanism), and have the AppContainer app have whatever access the mediumIL process had to that file? Failing that, can #175 be made to work on files? If I can do either of these, I can write my own file-access broker, bypassing StorageFile and all its overhead, while providing better privacy protection than the inbox solution does (e.g. user-selected read-only access, or access that expires when the app is closed). A sidecar app would be used to implement this.

@DrusTheAxe I would have asked you this in #105, but that issue is off-topic enough already. 😄

[DrusTheAxe]

Sorry I don't know. We're well into hardcore security land.

Perhaps @DefaultRyan or @jonwis or @ptorr-msft know more (or know who would)

[jonwis]

You're describing exactly how CreateFileFromApp works - if the calling app (an appcontainer) doesn't have access, CFFA invokes a runtimebroker object which is running as fulltrust, who then cross-checks that the calling app has been granted access by the user.

On Windows, access checks are performed at the time of creating a handle to an object. When the handle is created on behalf of your fulltrust process, it retains whatever access rights you requested (read, write, delete, etc.) If you duplicate that handle to another process, the new handle has the same access rights (unless you change it via the parameters to DuplicateHandle) but is then owned by the other process.

Duplicating handles across processes for IPC can be dangerous, especially manually converting a handle from HANDLE in the broker to UINT64 to pass across to the callee. You can instead use MIDL and RPCSS/DCOM's powers to correctly marshal handles across an interface - see https://docs.microsoft.com/en-us/windows/win32/midl/sh-file for details.

Precise answers:

• Yes, Duplicating a handle from a medium-IL process to a low-IL process works just fine
• The duplicated handle has the same access rights unless you modify them during Duplicate
• Yes you can do this from your own fulltrust sidecar if you want

If you haven't yet, consider checking out the CreateFileFromAppW family of APIs - those let you take a path to which your app has access and use the Win32 APIs on them, rather than using StorageFile.

[wjk]

Thanks so much @jonwis! The WinRT file picker APIs aren’t well designed (cf #88) and I want to use a standard Win32 IFileDialog instead, but I don’t think that class can be used (productively) directly in an AppContainer, as I don’t think it can grant AppContainer access, due to being a Windows 7-era API.

Also, there is no documentation for the *FromApp functions anywhere on docs.microsoft.com that I can find. While the function signatures are self-explanatory, the access semantics are not. You might want to look into that. 😄 Thanks!

[jonwis]

https://docs.microsoft.com/previous-versions/windows/desktop/legacy/mt846585(v=vs.85) and https://docs.microsoft.com/previous-versions/windows/desktop/legacy/mt846584(v=vs.85) ... I don't know why they're marked deprecated, they're very much alive and relevant. I'll ask around.

One caution is is that IFileDialog returns IShellItem, some of which are members of the shell namespace and may not be backed by a physical file object that can be opened and transmitted to the AppContainer.

[jonwis]

Doc team says they're looking into it and it should return in a few days. I'll poke the thread again when it's live.

[drewbatgit]

The APIs from fileapifromapp.h have been moved out of the archive and into the current docs:

https://docs.microsoft.com/en-us/windows/win32/api/fileapifromapp/

The previous-versions URLs above now redirect to the current API pages.