I've written a classic cross-volume file system mini-filter driver that redirects all I/O requests from one volume (C:) to another (say, T:). The basic aim here being - to ensure that the system volume i.e. C: doesn't get modified in anyway once the software (of which the driver is part of) is up and running.
I obviously do this by reparsing all the traffic from real volume i.e. C: to throw-away volume, let's call it T:. I've tested the mini-filter driver heavily. I ran it against software such as MS Office, MS Visual Studio, CodeBlocks etc. and it seemed to be working as expected as in all the I/O requests were redirected to volume T:, kept data on the system volume intact and all of this activity was transparent to the applications.
But during my testing, when I tried to launch UWP applications such as Calculator, Windows Photos etc. they just won't get launched. When clicked on a tile on task bar e.g. the calculator process gets created and it tries to initialize itself (I can see a calculator-sized blue screen coming up on the screen) but then it simply disappears without displaying any error information.
After reading up about UWP applications and how they are hosted inside AppContainer, I realized they run in the context of package sid which is different from the sid of logged on user. And the manner in which I was creating directories in the driver (with the default security descriptor) as and when they were accessed also did not help since that was basically resulting into apps receiving STATUS_ACCESS_DENIED error code. To get around this, I gave "ALL APPLICATION PACKAGES" and "ALL RESTRICTED APPLICATION PACKAGES" Full-control at the root of the throw-away volume and set "applies to" setting to "This folder, subfolder and all files". Now when the UWP app is launched, it should have access to all the directories created in the alternate locations since all of those directories now have inherited "ALL APPLICATION PACKAGES -> FullControl -> This folder, subfolder and all files" setting. But still the app fails to launch without displaying any error information.
After spending quite a bit of time investigating this, I came across this --> https://support.microsoft.com/en-ie/help/2798317/microsoft-store-apps-fail-to-start-if-default-registry-or-file-permiss
It basically says, The "All Application Packages" group (a well known group with a predefined SID) must have specific access to certain locations of the registry and file system for Microsoft Store Apps to function properly.
It looks like, giving full-control to ALL APPLICATION PACKAGES group won't do any good. It needs to have exact/specific access rights on each directory for the UWP apps to work?
Has anybody come across this/similar kind of issue. Any ideas as to how one can get around this ?
It looks like you're new here. If you want to get involved, click one of these buttons!
|Upcoming OSR Seminars|
|Writing WDF Drivers||21 Oct 2019||OSR Seminar Space & ONLINE|
|Internals & Software Drivers||18 Nov 2019||Dulles, VA|
|Kernel Debugging||30 Mar 2020||OSR Seminar Space|
|Developing Minifilters||27 Apr 2020||OSR Seminar Space & ONLINE|