使用Java的AclFileAttributeView获取通用文件夹权限（如GENERIC_ALL）

Question

I use the AclFileAttributeView from Java7 to read the folder permissions of a Windows directory. The problem is that I'm not able to get a complete overview because the AclFileAttributeView doesn't return generic permissions like GENERIC_ALL, GENERIC_WRITE, GENERIC_READ and GENERIC_EXECUTE (the four high-order bits in the access mask). In fact, when it comes to generic permissions it gives me wrong information about other AclEntries for the same member. Let me give an example:

When I use a tool like AccessChk to list the AclEntries of c:\\windows for the System account I get the following:

[2] ACCESS_ALLOWED_ACE_TYPE: NT AUTHORITY\SYSTEM
  FILE_ADD_FILE
  FILE_ADD_SUBDIRECTORY
  FILE_LIST_DIRECTORY
  FILE_READ_ATTRIBUTES
  FILE_READ_EA
  FILE_TRAVERSE
  FILE_WRITE_ATTRIBUTES
  FILE_WRITE_EA
  DELETE
  SYNCHRONIZE
  READ_CONTROL
[3] ACCESS_ALLOWED_ACE_TYPE: NT AUTHORITY\SYSTEM
    [OBJECT_INHERIT_ACE]
    [CONTAINER_INHERIT_ACE]
    [INHERIT_ONLY_ACE]
  GENERIC_ALL

As you can see the first AclEntry only applies to the folder itself and has the special permissions WRITE_ACL and WRITE_OWNER. The second AclEntry applies only to subfolders and files and contains the generic permission GENERIC_ALL. This is exactly how I see it in the Security tab of Windows Explorer. Two records for the System account, one applies only to the folder (with a subset of permissions) and one applies to subfolders/files with Full control.

Now I run my java program using the following code:

AclFileAttributeView view = Files.getFileAttributeView(path, AclFileAttributeView.class);
System.out.println(view.getAcl());

This gives my the following results for the System account:

• NT AUTHORITY\\SYSTEM:READ_DATA/WRITE_DATA/APPEND_DATA/READ_NAMED_ATTRS/WRITE_NAMED_ATTRS/EXECUTE/DELETE_CHILD/READ_ATTRIBUTES/WRITE_ATTRIBUTES/DELETE/READ_ACL/WRITE_ACL/WRITE_OWNER/SYNCHRONIZE:ALLOW
• NT AUTHORITY\\SYSTEM:FILE_INHERIT/DIRECTORY_INHERIT/INHERIT_ONLY:ALLOW

The first AclEntry applies only to the folder itself and contains the special permissions, including WRITE_ACL and WRITE_OWNER, which is not correct! The second AclEntry doesn't show any permissions, because it has GENERIC_ALL on it!

I'm not sure where this goes wrong, it seems the JRE just decodes the ACE bitmask given by the OS (sun.nio.fs.WindowsSecurityDescriptor.decode).

Has anyone experienced these same issues? I will try some other JRE's, perhaps that makes a difference.

Answer 1

I too ran into this same issue. As it turns out the spec for AclFileAttributeView states it is designed to be compatible with RFC 3530: Network File System (NFS) version 4 Protocol . In RFC 3530, there is no support for GENERIC_* values. I also looked at the JDK code source (From OpenJDK project downloaded from here ) which runs the JVM. While it seems to me that there would be a way to make the JVM compatible by mapping from the appropriate RFC 3530 flags to and from GENERIC_*, the maintainers clearly have not. This is the reason for your empty entry NT AUTHORITY\\SYSTEM:FILE_INHERIT/DIRECTORY_INHERIT/INHERIT_ONLY:ALLOW

Worse yet, the JVM does NOT support the SE_DACL_PROTECTED and SE_SACL_PROTECTED flags from Windows Security descriptors (which are set via the meta flags (UN)PROTECTED_(S/D)ACL_SECURITY_INFORMATION as indicated in comments here . If you use the tool AccessChk , it actually shows you the effective ACE list not the actual ACE list, which AclFileAttributeView and other Windows tools do (look at FileTest .) This is the reason why the number of ACEs are different. In my case, I had 9 ACEs but AccessChk showed 5. 4 out of those 9 where really duplicates on the SID (the user or group) value where the 1st ACE for a given SID had permissions and the 2nd ACE for a given SID had NO permissions, but just the SE_DACL_PROTECTED set or not set.

I'm not entirely sure what it is you wanted to DO with these ACLs, but I may have a solution for you depending upon your intent. I went ahead and made changes to the JNA project to start allowing one to modify Windows Security Descriptors in a more direct way. You can see my merged pull request here . I don't know how often they publish versions to the Maven public repo, so you may have to download and compile the source directly to get those changes. See the GetNamedSecurityInfo for how to get the SD of an object. Then, you can use the help APIs in AdvApi32Util to maninuplate the SECURITY_DESCRIPTOR objects. See public static SECURITY_DESCRIPTOR_RELATIVE getFileSecurityDescriptor(File file, boolean getSACL) for a way to get the SD into self relative format and then that object allows you to walk the ACEs in the ACL.

Answer 2

I ended up using reflection to get the ACE's access mask (using sun.nio.fs.WindowsNativeDispatcher.GetAce). With the access mask I check the four high order bits to determine the generic permissions.

It also allows me to get the INHERITED_ACE bit, which is not available in the JRE spec. I get the 'raw' ACL information, which is a lot more then the Windows Security tab. For example, my c:\\ drive gives me two ACE's for the BUILT-IN\\Administrators, one with GENERIC_ALL permissions and propagation to subfolders and files (not the container itself), and one with the applied special permissions having no flags at all (only applied on the current container). That's how Windows uses these Generic permissions. The same applies for the subfolders, like the Program Files directory, Generic permissions are propagated and every sub container has a separate ACE for the actual special permissions that apply only to the container itself.

About the tool AccessChck, are you sure you use the -l parameter? This gives a lot more information and the 'raw' ACL information.

I already use the JNA Project to retrieve local groups from a server. Thanks for the tip about the AdvApi32Util! I will look into it. How was your experience with the setACL method in the JRE?

I use all this to release a tool that combines group membership from a LDAP with the ACL information found in the directories and files. All this information is saved in a local database (or external) and can be used to create overviews. This overview offers a lot of filter options and displays permission info for a specific user or a group of users (including nested group membership). Because everything is saved in a database, it gives you overviews in seconds instead of scanning the whole network every time. You can also trace permissions, it displays where permissions come from, from what group membership or from what folder, etc. It will contain a feature to modify a single ACE, but the focus is on viewing permissions.

The tool is ready for testing ;) Let me know if you're interested... The tool won't be for free because it took me a hell of a lot time to write, but let me know if you're interested. I can get you a license. See the following links for a quick impression. Don't mind the website, it still mentions an old version of the tool.

Scan screenshot
Overview screenshot

Permission Analyzer 64bit
Permission Analyzer 32bit
Permission Analyzer 64bit with embedded JRE
Permission Analyzer 32bit with embedded JRE