ACL, ACE ... Permissions... How to handle File security?
Windows provide a built-in way for accessing information and checking user privilege to know whether one should be able to access a document/folder or not. In this article we will first make a little introduction to technical word. We will the present the way windows handles security on file/folder and the way to manage them. Then a section will introduce the notion of rights inheritance before evoking the notion of Owner and its function. Then a few "typical test cases" will be presented.
SID, Permission, ACE, ACL: barbarous words
A little understanding of technical word is needed to fully understand what we are talking about while discussing permission problem. All needed notion are sum up in the following drawing.
SID (Security Identifier) : user identity. This is basically the user login or the group name.
Permission : integer that represent the acess given to the associated SID (read, write, ...)
ACE (Access Control Entry): couple (SID, permission). It thus represent the acess that is given to a user/group
ACL (Access Control List): list of ACE sat on a given file of folder
Those informations can be displayed in the file/forder property (right click on the file) in the Security tab.
In that case Bruno Lenski is the SID of the user, the permission are listed below and the couple Bruno Lenski and its permission consist in the ACE. The ACL are the set of AC for Bruno Lenski and for Administrators
The above view of permission is the condense way windows display the permission it has on folder. To display the fill list of permission, one would have to click on the advance button in the above picture and get to the screen on the right. These permissions can be edited by clicking on the edit button.
Question to answer before granting permissions?
Before setting permission on a folder, there are few points to be considered:
Who will have access? Is that a set of user or a single user? (SID, list of SID)
How often do I expect that list of SID to change? (for instance in the case of a newcomer in the group, ...)
What are the rights to be granted for each SID?
To address the first and second point, one should be aware that, permission are set on file/folder level. Adding a new permission for a single user in a folder is not a trivial task as it implies modifying all ACL. It is strongly recommended to use Groups to give access to folder.
To address the third point, one should be aware that is strongly recommended to give access to resource and not to deny access. If someone is granted access then he would be able to access the resource. If someone is not given access then he would not be able to access the resource. Note that denying the access is another process that can have side effect (described below) and thus it is not recommended to use that functionality. (see the examples for more in formations) List of possible permission.
There are 13 permissions in windows whose names are understandable. These permissions are all stated in the table below all together with a parallel with Unix permissions:
| Windows Permissions | Unix Read | Unix Write | Unix Execute | Unix Delete |
|---|---|---|---|---|
| Traverse Folder / Execute Files | X | |||
| List Folder / Read Data | X | |||
| Read Attributes | X | X | ||
| Read Extended Attributes | X | |||
| Create Files / Write Data | X | |||
| Create Folders / Append Data | X | |||
| Write Attributes | X | |||
| Write Extended Attributes | X | |||
| Delete Subfolders and Files | ||||
| Delete | X | |||
| Read Permissions | X | X | X | |
| Change Permissions | ||||
| Take Ownership |
A few notes about this table:
Delete Subfolders and Files can be applied as an individual permission to folders.
There is actually a 14th permission component, called Synchronize. This permission is used to control synchronization of access to file or folder handles for multithreaded applications. It is sort of a "different bird" from the other permissions, which is why I mostly ignore it. :^)
Ownership and permission assignment
Every object within the NTFS volume has an owner, which is a user identified by the object as being the one who controls it. By default, the user who creates a file or folder becomes its owner. The significance of ownership is that the owner of a file or folder always has the ability to assign permissions for that object. The owner can decide what permissions should be applied to the object, controlling others' access to the file or folder.
The two special permissions that are associated with ownership and permission assignment are "Change Permissions" (P) and "Take Ownership" (O). If a user is granted the "Change Permissions" permission, the user can change the permission settings for the object even if he or she does not own it. If a user has "Take Ownership" permission, the user has the ability to take over ownership of the resource, and of course, once it is owned the user can do anything he or she wants with the permissions.
Note that by default, members of the "Administrators" user group can always take ownership of, or change permissions on, any file or folder. This allows administrators to fix permission problems if they occur. Thus wile assigning permission, removing/denying permission to the Administrator is pointless as these persons can reassign themselves all the rights.
Permission inheritance
The notion of inheritance is base on the notion of folder and subfolder. The permission sat on a parent folder can be propagated to all folders that it contains. an administrator or user is though inheritance able to manage a hierarchical tree of permissions that matches the hierarchical tree of directories. Since each child inherits permissions from its parent, when you set up a hierarchy of three or more levels of folders, the objects deep within the structure will inherit permissions from their parent, "grandparent", "great grand-parent" and so on.
In addition to this powerful dynamic inheritance feature, Windows offers several advanced inheritance control features that give the administrator more power over how inheritance works:
Child Protection: The main security properties dialog box for each object contains a check box labeled "Allow inheritable permissions from parent to propagate to this object". If the check in this box is cleared, this breaks the normal inheritance link between this child and its parent (and higher-level ancestors as well). When this is done, the child will no longer dynamically inherit permissions from higher up in the directory tree. Such a child object is said to be protected from inheritance changes.
Forced Propagation: An option called "Reset permissions on all child objects and enable propagation of inheritable permissions" is provided. This works the same way as the "Replace Permissions on Subdirectories" and "Replace Permissions on Existing Files" options from the older Windows NT static permission model. When selected, NTFS will force propagation down to all child objects and remove any permission that were directly assigned to those child objects. This allows administrators to easily "fix" permission problems in large directory structures.
Inheritance is thus a powerful tool even though it brings a disadvantage: performance. Inheritance requires more processing resources to deal with changes to files and folders, and to determine which permissions take precedence each time access to an object is attempted...
Permission resolution
Here is the thought part... how does the system interprets the list of ACL. How are permissions granted... this section might seems a bit technical but few examples afterwards will try to clarify the situation.
Here is the algorithm used to check weather one have access or not :
"Deny" permissions take precedence over "allow" permissions.
Permissions applied directly to an object take precedence over permissions inherited from a parent object.
Permissions inherited from near relatives take precedence over permissions inherited from distant predecessors. So permissions inherited from the object's parent folder take precedence over permissions inherited from the object's "grandparent" folder, and so on.
Permissions from different user groups that are at the same level (in terms of being directly-set or inherited, and in terms of being "deny" or "allow") are cumulative. So if a user is a member of two groups, one of which has an "allow" permission of "Read" and the other has an "allow" of "Write", the user will have both read and write permission--depending on the other rules above, of course. :^)
The system combines these rules into a process that it uses to resolve various permission settings. Since directly-applied permissions take precedence over inherited ones, and "deny" permissions take precedence over "allow" permissions, it first looks for directly-set "deny" permissions, combining them all together for all groups the user is a member off. If it finds sufficient deny permission to refuse access, it is done--the access is refused. Otherwise, it looks at directly-set "allow" permissions. If it finds sufficient permission to allow access, the access is allowed. If not, it continues on; the sequence is as follows:
Examples
Here is a set of example to explain the system behaviour. Let's assume I am Bruno lenski part of the IT-IS group.
In this example the inheritance of rights are removed from that folder.
Case 1:
If I create a folder in "My document", it has the following ACL :
Bruno lenski has full Control
Administrators has full Control
In that case Myself and administrators of the cenhome12 machine has access to the folder and its content.
All other person from IT-IS has no access.
Case 2:
I want my college from IT-IS to access this folder with read permission. I thus have to add the "User IT-IS" Group to the list of SID and allow them to have read rights. Note that this read rights for the user is composed of 3 different windows rights :
List folder /Read Data
Read Attributes
Read Extended Attributes
Restraining the right only to "List Folder/Read Attribute" would lead to have "Special permission" ticked instead of read.
Once a user X want to access then the resolution is done that, if he is member of IT-IS, he is granted the right.
As Bruno Lenski is member of IT-IS, he get the rights.
Case 3:
Let assume now, I now want to deny access to all person from IT-IS on that folder. I can apply a deny permission on the read rights to the IT-IS ACL. This then lead to the following behaviour. If a user X want to access, the system successfully check :
Is X member of IT-IS, if yes the access is denied.
If not, is X = Bruno Lenski, if yes the access is granted
If not is he in the cernhome12\Administrator Group
The problem now is that Bruno Lenski is member of IT/IS group though the first rule gives an access deny. So even if the second rule grant access, the first rule applies and thus Bruno lenski is NOT granted access.
Due to this behaviour, we recommend not using deny access.
Case 4:
Starting back from the status in case 2. Let assume I want people from TE-MSC to have access in read mode instead of IT-IS. Then I remove the IT-IS entry and add a TE-MSC entry with read rights. Thus if a user X presents and wants to read in the repository, the system will successively check :
Is X = Bruno Lenski, if yes he has full control
If not, is X member of Users TE-MSC
If not is he in the cernhome12\Administrator Group
If all test fail then the access will not be granted
Case 5:
Let's assume now, that I am creating a folder inside that folder. This folder inherits it the parent folder rights. Thus the security Tab is showing me the permission in grey. To remove this inheritance, one should click on "Advanced", to open the detail right windows. Then one should click on edit on that newly opened window and untick :
The system will then ask if the user want to remove all permission or copy the current permissions. Let's assume we remove the permission. The folder has then no SID and thus nobody has permission on that folder.
Nobody... No.. in fact the owner (person that created this folder) have the permission to change the permission. Then I can add myself permission on that folder.
The owner can be displayed by clicking on "Advanced" on the security tab and browse "Owner" tab.
Note that the machine administrator can always take ownership and thus give himself rights afterwards.
I can then add access to myself as having full control on the folder. The problem I face then is that I cannot grant access to Administrators anymore (in our case CERNHOME12\Administrators) thus, the folder will have backup problems.
Thus removing all permission is not good. I should have copied the permission instead of removing the permission when I was prompted.