UWP folder access permission denied using Win32 API

Question

I am porting libgit2 to get a Git GUI for UWP. A scenario is to let user pick a repository folder using FolderPicker::PickSingleFolderAsync and then add it to FutureAccessList so that the app can access it for the usual Git functionality. The problem is that the underlying Git code relies heavily on Win32 API file and folder access such as FindFirstFile, MoveFileEx, ... for file and folder stat, open, ... and the app reports Permission denied upon attempt to access it. (The code works well for folder inside the app's local storage. I also checked that usual stdio only works there. One cannot fopen outside of that.)

Is there a workable solution for this? Shouldn't permission be honored across different supported API, something I might have missed? (I wouldn't dare trying to port all the POSIX required by libgit2. On the one hand, it will be guaranteed to be inefficient. On the other, it is extremely error prone such as writing mmap that plays well with open.)

Try the solution [in this post](http://stackoverflow.com/questions/42799235/how-can-i-get-a-win32-handle-for-a-storagefile-or-storagefolder-in-uwp) - although it might not work exactly for you. — Peter Torr - MSFT, Mar 15 '17 at 01:06
@PeterTorr-MSFT Thank you for the pointer. Sadly, it does in principle but it does not help much in my case. The issue is that the majority of software that needs file access do so via file path. For the case in question, `libgit2` does not provide API to open a repository via folder's HANDLE. Unless I do the undesirable action of finding and redirecting all the possible Win32 API the library is using such as `MapViewOfFile`, etc. it will not work. — An Hoa, Mar 18 '17 at 20:21
Understood. This is a known limitation of the current platform. — Peter Torr - MSFT, Mar 19 '17 at 21:59
@PeterTorr-MSFT Thanks for acknowledging the problem. It would be great if the Win32 can be upgraded to take into account the `StorageFile` permission in a seamless way. (I mean when a user picked a `Storage(File|Folder)` via the picker, application should be able to access the underlying storage via the traditional API endpoint.) — An Hoa, Mar 22 '17 at 16:59
You can upvote [this UserVoice request](https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/15012810-honor-file-access-permission-across-win32-stdio-a). — Peter Torr - MSFT, Mar 23 '17 at 01:26

An Hoa · Accepted Answer · 2016-06-30T15:39:34.067

It is IMPOSSIBLE to achieve such thing!

According to @RobCaplan https://blogs.msdn.microsoft.com/wsdevsol/2012/12/04/skip-the-path-stick-to-the-storagefile/, the geniuses at Microsoft has invented a security storage solution that neither is secure nor backward compatible a.k.a. making developers' lives easier: Once the user grants an app the StorageFolder, the app can wreak havoc on it using the supplied StorageFile API. The following code

auto folderPicker = ref new Windows::Storage::Pickers::FolderPicker();
folderPicker->FileTypeFilter->Clear();
folderPicker->FileTypeFilter->Append("*");

create_task(folderPicker->PickSingleFolderAsync()).then([](Windows::Storage::StorageFolder^ folder)
{
    if (folder == nullptr)
        cancel_current_task();
    Windows::Storage::AccessCache::StorageApplicationPermissions::FutureAccessList->Add(folder);
    create_task(folder->GetItemsAsync()).then([](IVectorView<IStorageItem^>^ items)
    {
        // Delete the folder content or encrypt it and demand money
        auto iter = items->First();
        while (iter->HasCurrent)
        {
            create_task(iter->Current->DeleteAsync(StorageDeleteOption::PermanentDelete));
            iter->MoveNext();
        }
    });
});

will happily clear out the folder an unlucky user picks. A malicious app doesn't even need to use Win32 API to do that. Logically, API is not the cause of security problem. The existing UWP Win32 API obviously handles correctly local storage access so it should take minimal effort to support FutureAccessList in Win32 API; such desire to make UWP development difficult must be intentional. (There is no doubt that Centenial is NOT going to fly. Nobody wants to move from the great flexibility of Win32 to the UWP prison.)

EDIT: I should have written

It is IMPOSSIBLE to achieve such thing the way I wanted!

since the article does suggest a quick and very smart solution

If the library doesn’t have such an interface and you cannot add one then you will need to copy the StorageFile contents into the application data folder (likely in the TemporaryFolder) and then pass the path to the temporary copy to the library.

so in my situation, every time a user picks a repository folder, I can copy the whole folder to the local storage, operates on them and then copy the whole thing back to its original location. And of course "the way I wanted" above refers to the efficient one where you don't have to copy things back and forth.

You're right. StoreApp / UWP App use the 'App Container' Integrity level(IL). By using this IL, OS can make a sandbox for the apps - apps can't access the out of box, as of this question. But, for centennial, it use the 'Medium' Integrity level. This level is same with normal win32 apps. This means centennial apps have no sandbox like as uwp. BUT...but...this also cause the security risk. It's a double-edged sword... — Mamoru Satoh, Jun 30 '16 at 05:31
@pnp0a03 As I wrote, I don't think API access is the security problem. In recent history of real world security breaches, the main problem is always the **user** and the **fact of life** that makes it impossible to implement systems both usability friendly and secure: often, somebody is fooled and he/she can still be in UWP (I can for instance change the above code to become a ransomware). So there is **NO** security risk associated to Win32 apps. (In fact, when it comes to C/C++, most exploits come from buffer overflow, the inherent danger of pointers.) — An Hoa, Jun 30 '16 at 15:31

UWP folder access permission denied using Win32 API

1 Answers1