[ The PC Guide | Systems and Components Reference Guide | Hard Disk Drives | Hard Disk Logical Structures and File Systems | New Technology File System (NTFS) | NTFS Security and Permissions ]

Permission Resolution

Every time a user attempts a particular type of access to an object on NTFS, the system must determine if the access should be allowed. In theory, this is a simple matter of looking at the access control lists for the object, seeing what the permission settings are for the user, and determining if the desired access is allowed. Unfortunately, in reality, it's not this simple. :^) Since every object can have many different permission settings, it is possible that several different permission settings might apply to a particular object and access method. Furthermore, it is possible that these permission settings might conflict. When this occurs, the system must engage in a process of resolving the various permissions to determine which ones should govern the access.

Under the Windows NT permissions scheme, inheritance is static, so there is no issue with multiple inherited permission settings. Conflicts can still occur, however, because a particular user can have a permission associated with his user account and also a group of which he or she is a member--or, he or she could be a member of more than one user group. For example, user John may have permissions allowing him read permission on a particular file called "Struct01.acd". However, he may also be a member of the "Engineering" group, and that group may have both read and write access to that same file. There are two rules that are used for resolving permissions in the Windows NT scheme:

1. With the exception of the "No Access" permission group, Windows NT permissions are all "positive"--meaning, they grant permissions, rather than taking them away. Therefore, the more "inclusive" of the permission settings takes precedence. In the example above, John would be allowed read and write access on "Struct01.acd" because the permission he gains as a member of the "Engineering" group is more inclusive than the one he was granted personally.
2. The "No Access" permission group is the only one that has "negative" permissions--it denies access instead of giving it. As such, it is given special status: it trumps rule #1. If someone has "No Access" permission to an object, they are denied all access to the object regardless of any other permissions. So in the example above, if John was also a member of the "Accounting" group, and that group had "No Access" permissions for the file "Struct01.acd", John would be totally out of luck, regardless of his other rights settings. This is the reason why "No Access" must be used very carefully!

Windows 2000 offers much better control over how permissions are assigned, as well as the benefits of dynamic inheritance and advanced inheritance control. However, these extra features make permission resolution much more complicated. In addition to the potential conflicts caused by users being in more than one user group, as above, you can have conflicts between permissions that were set for the object directly and those that were inherited from any of the object's predecessors: its parent, grandparent and so on. Furthermore, the existence of both "allow" and "deny" permissions complicates matters further. To deal with these complexities, Windows 2000 uses an algorithm that follows these general rules:

1. "Deny" permissions take precedence over "allow" permissions.
2. Permissions applied directly to an object take precedence over permissions inherited from a parent object.
3. 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.
4. 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:

1. All directly-set "deny" permissions.
2. All directly-set "allow" permissions.
3. All "deny" permissions inherited from the parent.
4. All "allow" permissions inherited from the parent.
5. All "deny" permissions inherited from the grandparent.
6. All "allow" permissions inherited from the grandparent.
7. etc...

Well, this is certainly quite a bit more involved to explain than the NT permission resolution process--but that's the price you pay for the much more capable system implemented in Windows 2000. It's also not that difficult to understand once you get used to it. ;^) Here's an example that may help you to understand what's going on. Note that I am going to use only non-overlapping user groups to try to keep things somewhat manageable and not confuse you further. :^) Let's suppose we have the following permissions set on a structure:

• For folder "C:\Documents", group "Everyone" has an "allow" permission of "Read".
• For folder "C:\Documents\Exec", group "Employees" has a "deny" permission of "Modify", groups "Exec" and "Top Exec" have "allow" permission of "Modify" and group "Assistants" has "allow" permission of "Write".
• For folder "C:\Documents\Exec\Payroll-Projections", group "Assistants" has "deny" permission of "Modify" and group "Exec" has "deny" permission of "Write".

Every member of the company is a member of "Everyone". All department managers and higher executives are members of group "Exec", and their assistants are members of "Assistants". All lower-level managers and workers are members of "Employees". The president and vice-president are members of groups "Exec" and "Top Exec". Now, consider the following access attempts:

• Randy, who is a member of "Employees", tries to read a document in the "C:\Documents\Exec\Payroll-Projections" folder. There are no directly-set permissions that apply to him, but that folder inherits a "deny" on "Employees" from its parent. Randy will fail in his attempt.
• Jane, who is the director of Marketing and a member of "Exec", tries to write a document in the "C:\Documents\Exec" folder. She will succeed because "Exec" has an "allow" permission of "Modify".
• Jane tries to modify a payroll projection in the "C:\Documents\Exec\Payroll-Projections" folder. She will fail because "Exec" is denied permission to write in that folder. The directly-set deny takes precedence over the "allow" at the parent level.
• Lisa, who is the vice-president, attempts to modify a payroll projection in the "C:\Documents\Exec\Payroll-Projections" folder. She will succeed because "Top Exec" has not been denied at that folder level; it will inherit the "Top Exec" "allow" permission of "Modify" from the parent.

That probably isn't the best of examples, but this page has already taken way too long to write, so it will have to do. :^) At any rate, it gives you an idea of the power you have with the Windows 2000 NTFS permissions system--and how much extra work the system has to do when it needs to figure out whether someone is allowed to do something with a particular file or folder.

Next: Auditing

Home  -  Search  -  Topics  -  Up