Odd PowerShell Get-ACL permission translations

Question

I have a PowerShell script that matches Get-ACL Access Control Entries to standard Windows permissions using the access mask. Oddly, ACEs like "ReadAndExecute, Synchronize" seem to yield a permission of "FullControl". Here is the script:

 #Match current ACE permissions to regular permissions via access mask comparison (binary and / -band)
    $acl = Get-Acl "C:\Program Files (x86)"             
    $accesses = $acl.Access
    #Enumerate current directory's access rights
    foreach ($access in $accesses) {
            $Enumeration = $access.FileSystemRights
            $keys = @()
            [System.Enum]::GetValues($Enumeration.GetType()) | Where-Object { $Enumeration -band $_; write-host ($Enumeration -band $_) -ForegroundColor Red} | % {write-host -ForegroundColor Green $_;} | Select-Object -Unique | ForEach-Object { write-host -ForegroundColor Cyan $_; $keys += $_ }             
            $keys
    }

Perhaps I do not fully understand how to appropriately translate these Access Control Entries. It seems odd to me that "Modify, Synchronize" would somehow end up in the permission setting of "FullControl".

Also, if this script is run on your own system you will note the rather messy debug format it currently portrays. The "0"'s are simply non-matching results from the binary "and". The green values are the resultant Windows permissions from the ACEs that had matching access masks for the specified Windows permission (supposedly).

I hope that I am not repeating anything with this question; I've dug and haven't found an answer that explains this to me at my current level of understanding.

$Enumeration -band $_; -> ($Enumeration -band $_) -eq $_; — user4003407
@PetSerAl Thanks! I'm still pretty new to this; what do I gain by comparing the result of the binary and with the original set of types that were passed in? Appreciate the help — Shrout1
@PetSerAl Ok I get it :) I'm getting some odd collisions between my mask that being passed in and the mask that's being evaluated. The binary and of Full Control and Read and Execute happens to equal Read And Execute. Odd coincidental collision. — Shrout1

Shrout1 Shrout1 · Accepted Answer · 2016-07-27T16:46:14

I have to credit PetSerAl with giving me the comment that led to this answer. As it's been two days and he has not provided his comment in answer form I will self answer.

The odd results that I am seeing are actually a result of a "Collision" so to speak between the binary "AND" operation intended to validate the permission and the permission type being tested against.

The initial value (permission) cannot be directly compared with the permission type being checked as the objects are apparently incompatible. By running a binary AND on the permission value and the value being tested it can then be checked to see if the tested value actually is the permission being checked for. For some reason the binary AND operation results in an object that can be directly tested.

After the binary AND has been completed the result then needs to be compared to the permission type that was passed into the binary "AND" operator. Here is the modified code:

 #Match current ACE permissions to regular permissions via access mask comparison (binary and / -band)
    $acl = Get-Acl "C:\Program Files (x86)"             
    $accesses = $acl.Access
    #Enumerate current directory's access rights
    foreach ($access in $accesses) {
            $Enumeration = $access.FileSystemRights
            $keys = @()
            [System.Enum]::GetValues($Enumeration.GetType()) | Where-Object { ($Enumeration -band $_) -eq $_; write-host ($Enumeration -band $_) -ForegroundColor Red} | % {write-host -ForegroundColor Green $_;} | Select-Object -Unique | ForEach-Object { write-host -ForegroundColor Cyan $_; $keys += $_ }                
            $keys
    }

This comparison is to verify that any resultant permission from the value being checked and the type it is being checked against represent the value being checked and not a collision of binary values resulting in a different permission altogether.

For example, "ReadAndExecute, Modify" when represented by $Enumeration & ANDed with "FullControl" result in "ReadAndExecute, Modify" - this is a collision. While the "ReadAndExecute, Modify" permission is valid, the check was actually to see whether or not the Binary AND would result in "FullControl". The second check is to verify that the result is actually "FullControl" and not just any other valid permission type. This inability to compare without the "-band" operation leads to the addition of -eq $_ in the line Where-Object { ($Enumeration -band $_) -eq $_ }

Odd PowerShell Get-ACL permission translations

1 Answers