If you haven't read my earlier article on security, you might want to do that first. This article is going to dig deeper into Vault's the security framework. That's right, there's even more. The good news is that the hard stuff is over. Now that you know what an ACL is an how it's used to calculate the read, write and delete permissions, we can talk about how ACLs are hooked to files.
A folder can have an ACL on it. That ACL will not only apply to the folder itself, but it also applies to any files in that folder. If a sub-folder is created, it will inherit the ACL from the parent folder, but this can be changed later on. When you change the ACL on a folder it immediately applies to the files in that folder. There are also some options for propagating the changes to sub-folders.
A file can have 2 ACLs on it. One comes from its parent Folder and the other one is something called a System ACL. If present, the System ACL overrides the Folder's ACL. The 2 ACLs are not merged in any way. The System ACL completely wins out. So you may find cases where the folder says that the user has read only access, but they can edit certain files in the folder.
There are various ways to set the System ACL:
- If the Vault is not set up to use Item security, then the file's lifecycle state dictates the System ACL.
- If the Vault is set up to use Item security, then the item's security settings dictate the System ACL. This is only for cases where the file is linked to an Item and the Item is in the Released state.
- The file's System ACL can be set explicitly in the Properties dialog under the file menu (not to be confused with the Properties grid). Setting the System ACL in this manner will overwrite any file or item lifecycle security settings. At the API level, you use SecurityService.SetSystemACLs().
Regardless of how the System ACL is set, you can read it using SecurityService.GetEntACLsByEntityIds(). Even nicer is that the function returns both the regular ACL (the one from the folder security) and System ACL.