Share via


File and Folder Permission Problem in Windows 10 v1809

Question

Monday, March 11, 2019 12:53 AM

There appears to be a serious bug in Windows 10 v1809.

To reproduce the symptom, try this using default Windows GUI tools:

1. Create an arbitrary file, named "TEST" for example.
2. Remove file permission inheritance from TEST. ("Disable Inheritance", choose to copy permissions.)
3. Assign "ALL APPLICATION PACKAGES" permissions to TEST. (Any permission(s), it doesn't matter). You'll need to use "Advanced/Find Now" to locate "ALL APPLICATION PACKAGES".
4. Save your settings.
5. Attempt to remove permissions for "ALL APPLICATION PACKAGES".
6. Observe that you can't remove permissions for "ALL APPLICATION PACKAGES".Is this going to be fixed? We don't see this issue on previous versions of Windows 10.

Lance Simmons

All replies (10)

Tuesday, March 12, 2019 3:20 AM âś…Answered

We have been informed by Microsoft that this behavior is "by design".

ALL APPLICATION PACKAGES supports UWP apps and if you assign it permissions, Windows then attempts to "protect" them.

So, not a bug. An undocumented feature!

Lance Simmons


Monday, March 11, 2019 2:39 AM

I have few users reported this but it was a previous version of win10 , please try cleaning the registry permissions in the default Domain Group Policy and see if that fixes. I do not see any specific issue related to this is reported for the v1809.

Please refer this..

https://support.microsoft.com/en-us/help/2798317/microsoft-store-apps-fail-to-start-if-default-registry-or-file-permiss

Let me know


Monday, March 11, 2019 5:16 PM

Hello,

No, I'm sorry, but that has nothing to do with the issue I'm describing.

Have you followed the steps I outlined above?

You'll need to do exactly what I describe, on Windows 10 v1809.

Some of the steps do require in-depth knowledge and understanding of Windows file system security.

If you're unable to accomplish each item, perhaps I can assist with a more detailed explanation of how to configure Windows 10 file system security. There are many resources on the Web as well.

Thank you.

Lance Simmons


Monday, March 11, 2019 8:02 PM

Here's a picture which may help.

Construct a file with permissions similar to those in the illustration below, and save your settings.

(Notice that inheritance has been disabled.)

Then re-edit the file permissions and attempt to remove "ALL APPLICATION PACKAGES".

On Windows 10 v1809, you can't. In other words, file system security is broken.

Lance Simmons


Monday, March 11, 2019 8:25 PM

Yep, I recreated your problem. I found one web site that said it was a win32 api bug. So far I'm unsuccessful in removing that acl. 


Monday, March 11, 2019 9:12 PM

It just won't go away. I've tried icacls, subinacl, and powershell. By name and by sid. No luck.

C:\Temp\hang>c:\Utils\Subinacl\subinacl.exe /file bad.txt /replace=S-1-15-2-1=S-1-1-0
C:\Temp\hang\bad.txt : replace Perm. ACE 0 all application packages with everyone
C:\Temp\hang\bad.txt : replace Perm. ACE 1 all application packages with everyone
C:\Temp\hang\bad.txt : 2 change(s)

Elapsed Time: 00 00:00:00
Done:        1, Modified        1, Failed        0, Syntax errors        0
Last Done  : C:\Temp\hang\bad.txt

PS C:\WINDOWS\system32> $target = 'C:\Temp\hang\bad.txt'
$acl = get-acl $target
  $aces = $acl.Access
    foreach ($ace in $aces) {
        "Found $($ace.IdentityReference) "
        if ($ace.IsInherited -eq $FALSE) {       
            Write-Host "Removing $($ace.IdentityReference) on $target"
            $acl.RemoveAccessRule($ace)
            Set-Acl  $target $acl
        }
   }

Found APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
Removing APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES on C:\Temp\hang\bad.txt
Exception calling "RemoveAccessRule" with "1" argument(s): "Some or all identity references could not be translated."
At line:8 char:13
+             $acl.RemoveAccessRule($ace)
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : IdentityNotMappedException
 
Found BUILTIN\Users

If you have a Win7 or Server2008 system, try mapping a drive to the folder where your test file is and try to set permissions from there.  


Tuesday, March 12, 2019 12:51 AM

Very good!

You reproduced the issue.

Now what?

Can we expect a hotfix from Microsoft?

If not, I guess we're stuck with file system permissions we can't get rid of?

What a ridiculous situation.

Lance Simmons


Tuesday, March 12, 2019 3:45 PM | 1 vote

We have been informed by Microsoft that this behavior is "by design".

Is that documented anywhere? 


Wednesday, March 13, 2019 3:54 AM

This is all we were told.

... the ALL APPLICATION PACKAGES group should only be granted limited "special permissions" (Read/Execute/List) to 
these locations.  This account has been a well-known built-in SID (S-1-15-2-1:  https://docs.microsoft.com/en-us/
openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab) since Windows 8 to support UWP apps.  If the 
group is explicitly granted permissions to a new file/folder (not recommended), the OS will attempt to protect them 
unless the file/folder is deleted, as it is trying to ensure core UWP app functionality.  This is also expected behavior
 for the ALL APPLICATION PACKAGES group/Windows 10.  

Lance Simmons


Wednesday, March 13, 2019 1:41 PM

Thanks Lance.