Importance of NTFS Permissions and How to Read Access Control Lists
"Windows Security" is a broad title; this thread is well defined, we're clearly on the topic of
NTFS permissions.
I'm going to begin by saying that the topic of NTFS permissions is involved for a large many, and when I say 'many' I am referring to the population of technical folk too, power users and gurus alike... and if I had to say it, I reckon a great majority of the experts on this forum do not understand the concept of permissions themselves well enough to be giving advice how permissions should be arranged.
NTFS permissions is the glue that holds Windows together: Windows, as it stands right now, could not operate on any other filesystem because of how bound to NTFS permissions it’s become. Windows relies on NTFS permissions, and NTFS is here to stay for a long time, so I highly recommend that you, reading this, get moderately acquainted to the most confusing part of NTFS. Understanding how permissions work in Windows will significantly help in understanding how Windows works in general. NTFS permissions does not have to be such a difficult concept. If we all just took the time to read about how they work, and practised using them frequently enough, there wouldn't be so many misconceptions and false ideas given by many tutorials and individuals pertaining to how permissions really work.
Permissions tend to stump me too at times because there's so much of it everywhere it can be a real headache to manage. Many objects in Windows have permissions on them, and there are a number of types of objects in Windows that have their own sets of access rules. These different objects are called Securable Objects and can have permissions. A list of securable objects include the Filesystem (the common variety that really gets to us when we're faced with that all too familiar "Access is Denied” message when doing something to a file), Registry keys, Processes, Services, Shares, and the list continues. Almost everything in Windows carries permissions.
I cannot explain all there is to know about permissions in Windows here, it'll take pages and pages. If you are interested in knowing how NTFS permissions work, I recommend giving
this documentation a thorough read through, and then practise modifying permissions yourself.
If you're really up for it and have a strong understanding of how Windows works, I recommend the TechNet documentation concerning NTFS permissions which can be found
here.
I'm not just going to leave a stack of reading for everyone to do, and you empty handed, Kefren. Just so you can get the gist of how Windows permissions work, I'm going to explain how one can read the Access Control List (ACL) of a filesystem object (such as a file, directory or drive) in an extremely cut-down, brief way, with examples to follow.
Firstly, I’d like to skim across a few terms. I’ll define each of them in the most layman way possible:
- Access Control List (ACL): basically the list you see when you view the security tab on a file,
- A Principal: a single user, a group, a service, or other object with an SID,
- Access rule / Permission: basically the things that govern what you can do with the object (e.g. Write, Read, Full Access),
- Access Control Entry (ACE): Allow or Deny (Type) + Principal + Access rule(s)
(for a more detailed description of terms see
this wonderful page)
The first thing to keep in mind when viewing an ACL (the list you see when viewing a file's security tab), is the order of permission precedence. Permission precedence says that all Deny permissions take precedence over Allow permissions, except for Explicit Allow permissions which take precedence over Inherited Deny permissions (in my experience, these cases are actually quite rare to come across. You can safely get by by just assuming that all Deny permissions will precede Allow permissions). The following list summarises permission precedence,
- Explicit Deny
- Explicit Allow
- Inherited Deny
- Inherited Allow
An Inherited permission just means that the permission was acquired from the object above it (a directory in the case of filesystem permissions). An Explicit permission, on the other hand, is a permission that only applies to the object it’s defined on.
The other important thing is knowing what Access Control Entry (ACE) is relevant to you (your logged in user). You’re either a specific user or you’re not; your either part of a group or your not. It’ll make sense with a few examples...
Another point, if your user isn't mentioned on the ACL at all, you are denied (full access). This means that if an ACL has no ACEs, then no one has access to that object, only the owner of that object would be able to make permission changes.
Note
Ownership is a separate but related concept to Permissions. The owner of an object does not (directly) give that owner more rights to that object. The owner of an object simply allows them to make permission changes to that object regardless of what the ACL of that object contains.
And the finial point of importance that you must know to understand how permissions are decided is the cascading nature of the access rules. Again, this'll make sense after an example.
To keep things simple, I'm going ignore the concept of inheritance in these examples. Also, I'm going to limit the access rules used to Read, Write and Execute.
The Scenario
Alice, Jake, Sally, and Ben share a machine. Along with the Everyone group, the groups that these users are a members of are summarised below,
- Alice: Users, Administrators;
- Jake: Users, Administrators;
- Sally: Users;
- Ben: Users, Guests
Eg 1: There is one ACE on a certain file, “OrangeCheese.txt”, that ACE being Users (group) which has the access rules of Read, Write and Execute. What permissions does Alice have and why?
This is what the ACL would look like for “OrangeCheese.txt”,
Code:
+--------+-------+-----------+----------------------+
| Object | Type | Principal | Access |
+--------+-------+-----------+----------------------+
| Group | Allow | Users | Read, Write, Execute |
+--------+-------+-----------+----------------------+
A: Alice would have Read, Write, and Execute access because Alice is apart of the Users group.
Eg 2: A file has three ACEs in it’s ACL. These ACEs are Users, which has the access rule of Read, Administrators, which has the access rule of Write, and Everyone, which has the access rule of Execute. What permissions does Alice have, and what permissions does Ben have?
A visual of the ACL,
Code:
+--------+-------+----------------+---------+
| Object | Type | Principal | Access |
+--------+-------+----------------+---------+
| Group | Allow | Users | Read |
| Group | Allow | Administrators | Write |
| Group | Allow | Everyone | Execute |
+--------+-------+----------------+---------+
A: Alice has all three access rights, Read given from the Users ACE, Write given from the Administrators ACE, and Execute given from the Everyone ACE. Ben, on the other hand, has Read given form Users, and Execute given from Everyone.
Eg 3: There are two ACEs in the ACL of the file “Carrot-Cake-Recipe.docx”. Those ACEs are Alice, whose access rules are Read and Execute, and Sally, whose access rules are Write and Execute. What permissions does Alice have, and what permissions does Ben have and why?
The ACL of “Carrot-Cake-Recipe.docx” in visual format,
Code:
+--------+-------+-----------+----------------+
| Object | Type | Principal | Access |
+--------+-------+-----------+----------------+
| User | Allow | Alice | Read, Execute |
| User | Allow | Sally | Write, Execute |
+--------+-------+-----------+----------------+
A: Alice has the permissions of Read, Execute (granted by the Alice ACE) as well as Write access (granted by the Users ACE), while Ben would be denied full access as he is not "mentioned" in the ACL.
Eg 4: A file has 4 ACEs in it’s ACL: Sally with Read and Execute access; Alice with Read and Write access; Users Denied Execute access; and Jake with Execute access. What permissions do these users have?
The file’s ACL,
Code:
+--------+-------+-----------+---------------+
| Object | Type | Principal | Access |
+--------+-------+-----------+---------------+
| User | Allow | Sally | Read, Execute |
| User | Allow | Alice | Read, Write |
| Group | Deny | Users | Execute |
| User | Allow | Jake | Execute |
+--------+-------+-----------+---------------+
A: Sally has only Read access because the Users ACE denies her from Execute. Deny permissions take precedence over Allows. Alice has Read and Write access. And lastly, Jake has no access whatsoever. Although the Jake ACE is allowing the user, Jake, Execute access, the Users ACE denies Jake Execute as it is a Deny permission and will take precedence.
Eg 5: There are 6 ACEs in the ACL of a file. The ACEs are,
- Alice, Read and Execute access;
- Jake, Write access;
- Sally, Read;
- Administrators, Read, Write and Execute;
- Users, Denied Write;
- Guests, Denied Read and Execute
The ACL looks like this,
Code:
+--------+-------+----------------+----------------------+
| Object | Type | Principal | Access |
+--------+-------+----------------+----------------------+
| User | Allow | Alice | Read, Execute |
| User | Allow | Jake | Write |
| User | Allow | Sally | Read |
| Group | Allow | Administrators | Read, Write, Execute |
| Group | Deny | Users | Write |
| Group | Deny | Guests | Read, Execute |
+--------+-------+----------------+----------------------+
What permissions do Alice, Jake, Sally, and Ben have? You guys can help me answer this one.
