none
Get-Acl List Permissions Question RRS feed

  • General discussion

  • I am trying to use Get-Acl to retrieve all group permissions on a folder object that only have read or modify permissions. However, when returning permissions, the Get-Acl commandlet is returning List as ReadAndExecute.

    Is there a way to drill deeper, or to differentiate List permissions from Read/Read and Execute?

    Monday, August 10, 2015 4:52 PM

All replies

  • If that is the permission that is set then that is what will return. 

    ReadExecute does not include Modify.

    Your question is rather vague.  Why not just say what you are trying to do and don't mention how you want to do it.


    \_(ツ)_/

    Monday, August 10, 2015 5:05 PM
  • My apologies for the vagueness; let me try again.

    On occasion we receive requests to give folder owners a list of permissions to folders to which they are the POC. I am trying to script this as it can become time consuming. What I would like returned is a list of groups against each folder that either have Read or Modify permissions against it; I want to filter out groups that only have the List permission against the folder.

    Using Get-Acl, I am getting what I want with regards to the Modify permission. Groups that have Read or Read/Execute permission are returning 'ReadAndExecute'. However, groups that only have List against the folder are also being returned as 'ReadAndExecute'.

    So my question was, is there a way to filter out groups that only have List permission? The syntax I am using is listed below, with following results (in this folder, BUILTIN\Users has List permission only).

    $allgrp = (Get-Acl -path <path>).AccessToString

    PS C:\> (get-acl -path c:\testfolder).AccessToString
    BUILTIN\Users Allow  Modify, Synchronize
    BUILTIN\Administrators Allow  FullControl
    NT AUTHORITY\SYSTEM Allow  FullControl
    BUILTIN\Users Allow  ReadAndExecute, Synchronize

    Monday, August 10, 2015 6:00 PM
  • If a group or user has ONLY list permissions you will see that.  If they have other permissions they will likely be combined as Modify or FullControl.

    It is unlikely that any account  has only list permissions.

    You are still saying how and not why.  The how is getting in the way of understand your purpose and in the way of you understanding the answers.


    \_(ツ)_/

    Monday, August 10, 2015 6:07 PM
  • It is not possible to understand what it is you are asking but here is something you can play with.

    The list capability is a result of one or more flags in a bit mask. You can get the integer value of the mask and test the flags as needed too see which permissions are included.


    \_(ツ)_/

    Monday, August 10, 2015 6:11 PM
  • Honestly, I don't know how else to word it, so I'll just throw in the towel and hope I can figure it out on my own.

    List permission is used a lot here, as people have permissions only to folders several levels deep, so they need List to be able to browse the entire structure to get to the folder they need.

    I created a folder on the root of my C: drive, applied List (everything else unchecked, no inheritance) to the Users group, and it comes back as ReadAndExecute. Effective permissions show it as List, yet Get-Acl returns ReadAndExecute. I have the same behavior on every folder I try it on. Maybe there is another commandlet I can use, but this one seemed to be the one I would use.

    Thank you for attempting to help, but as I stated earlier, I can't word it any differently than 'I need permissions on a folder of groups that only have read or modify permissions. FullControl I don't need, and List I don't need.'

    Monday, August 10, 2015 7:32 PM
  • Hi,

    You might have better luck with this module instead of using Get-Acl by itself:

    https://gallery.technet.microsoft.com/scriptcenter/PowerShellAccessControl-d3be7b83


    Monday, August 10, 2015 7:35 PM
  • All users with permissions generally have "list" permission.

    I recommend taking some time to learn about NTFS permssions;  what they are and how they are used.

    You might have this:

    FileSystemRights  : -536805376
    AccessControlType : Allow
    IdentityReference : NT AUTHORITY\Authenticated Users
    IsInherited       : True
    InheritanceFlags  : ContainerInherit, ObjectInherit
    PropagationFlags  : InheritOnly

    Do you see "list" anywhere there?

    Use Mike's link above.


    \_(ツ)_/


    • Edited by jrv Monday, August 10, 2015 10:21 PM
    Monday, August 10, 2015 10:18 PM
  • "List folder contents" means the same thing as "Read & Execute". Well, almost. Each permission you're seeing from Get-Acl is an access control entry (ACE) consists of the following things:

    • A type (Allow or Deny)
    • A principal (User/Group/Computer/etc)
    • Numeric rights
    • Inheritance and propagation flags ("Applies to")
    • A flag saying whether or not the permission is inherited
    That's an over simplified view of what makes up an ACE, but using the AccessToString is even more simplified than that. It cuts off the last two parts: the "applies to" and whether or not the ACE is inherited.
    Instead, try to use the Access property:
    (Get-Acl C:\Windows).Access | Format-Table

    When you do that, you'll see all of the information I listed above. The big difference is that most of the rights you see won't look numeric. They are, though. Try this:
    Get-Acl 'C:\' | 
        select @{N="Path"; E={ Convert-Path $_.Path }} -ExpandProperty Access |
        select Path, FileSystemRights, @{N="NumericRights"; E={$_.FileSystemRights.value__ }}
    

    What the Access property shows you is a pretty friendly view of what ACEs the security descriptor contains. It's not as friendly as the ACL Editor GUI, though. The GUI does some neat things, like...

    • Translating generic rights (jrv's example showed some generic rights--rights that aren't defined in the .NET Framework's FileSystemRights enumeration)
    • Merging ACEs (sometimes an ACL contains two or more ACEs that can actually be represented by a single ACE)
    • Giving different text descriptions to for the numeric rights and inheritance/propagation flags.

    The GUI doesn't change the underlying security descriptor when it does those things, but it presents them to you in a way that's easier to read. The module that Mike linked to above does the first two things (translating generic rights and merging ACEs), but it doesn't do the third one (yet). If you think about it, though, the built in PowerShell/.NET Framework numeric rights translation is pretty close. It gets the numeric rights translation right, it just doesn't take the inheritance and propagation flags into consideration.

    After all that setup, let's go back to what I originally said: "List folder contents" means almost the same thing as "Read & Execute". The numeric rights are exactly the same for each one. The only difference is that "List folder contents" doesn't apply to files (aka 'objects'...folders would be 'containers'). That means you would need the inheritance flags to be 'ContainerInherit' and the propagation flags to be 'None'. "Read & Execute" applies to the folder, subfolders, and files, which means the inheritance flags would be 'ContainerInherit, ObjectInherit' and the propagation flags would be 'None'. Using the 'Access' property, go back and look at the ACE(s) that you created for testing, and compare the 'InheritanceFlags' properties...

    TL;DR: The only difference between what the GUI calls "List folder contents" and "Read & Execute" is that the first one doesn't apply to files, so it's missing the 'ObjectInherit' ACE flag.

    Tuesday, August 11, 2015 2:06 AM
  • To add to Rohn's explanation:

    [Enum]::GetValues([System.Security.AccessControl.FileSystemRights]) |

      Select-Object @{n='Name';e={ [String]$_ }}, @{n='Value';e={ $_.value__ }}

    If you run that and look at the result you will not see any "List" permission.  List is part of "Read and Execute" along woth "Full Control" and other aggregate names.  They all define a bitmask that includes ReadData and other settings.

    If you scan and mask for ReadData it should get you close.   I believe that to do that you need to return the integer value ooof themask and bit and it with the  flag (0x1).  I haven't bit twiddled NTFS perms for a while now.


    \_(ツ)_/

    Tuesday, August 11, 2015 2:24 AM
  • Oh, I almost forgot an example of how to show the difference b/w "List folder contents" and "Read & Execute":

    dir C:\folder -Recurse | ForEach-Object { # This is to make sure Get-Acl errors don't stop the whole pipeline
        $_ | Get-Acl | 
            select @{N="Path"; E={ Convert-Path $_.Path }} -ExpandProperty Access |
            Add-Member -MemberType ScriptProperty -Name FileSystemRightsString -Value {
                if ($this.FileSystemRights -eq "ReadAndExecute, Synchronize" -and (-not ($this.InheritanceFlags -band "ObjectInherit"))) {
                    "ListFolderContents"
                }
                elseif ($false) {
                    # You can do more checks if you want to change more than just
                    # ListFolderContents...
                }
                else {
                    $this.FileSystemRights.ToString()
                }
            } -PassThru -Force
    } | Tee-Object -Variable aces | Out-GridView
    After that, $aces will contain all of the ACEs. If you want to get rid of the 'ListFolderContents', you can do that easily enough. Of course, if you have no use for even seeing the ACEs with 'ListFolderContents', you can restructure that example by getting rid of Add-Member and putting the FileSystemRights and InheritanceFlags check inside of a Where-Object scriptblock.


    • Edited by Rohn Edwards Tuesday, August 11, 2015 12:17 PM Fixed typos
    Tuesday, August 11, 2015 2:44 AM
  • Get-Acl <folder> | select -expand Access | Format-Table
    Can't we just do this?
    Friday, June 22, 2018 8:31 PM
  • Get-Acl <folder> | select -expand Access | Format-Table
    Can't we just do this?

    The whole point of the discussion will show you why this doesn't answer the OPs question.


    \_(ツ)_/

    Friday, June 22, 2018 8:41 PM