Access Control

Previous Topic Next Topic

Order of ACEs in a DACL

The preferred order of ACEs in a DACL is called the canonical order. For Windows 2000, the canonical order is the following:

Figure 12.24 shows the canonical order.

Figure 12.24    Canonical Order of ACEs
Enlarge figure

Figure 12.24 Canonical Order of ACEs

The canonical order ensures that an explicit access-denied ACE is enforced regardless of any explicit access-allowed ACE. This means that the object's owner can define permissions that allow access to a group of users, such as Everyone, but deny access to a subset of the group, such as Marketing. If the object's ACEs are in canonical order, the ACE that denies Marketing comes before the ACE that allows Everyone. During an access check, the operating system steps through the ACEs in the order in which they appear in the object's DACL, so the deny ACE is processed before the allow ACE. As a result, users who are members of the Marketing group are denied access. Everyone else is allowed access to the object.

The canonical order also ensures that all explicit ACEs are processed before any inherited ACE. This is consistent with the concept of discretionary access control: access to a child object is at the discretion of the child's owner, not the parent's owner. The owner of a child object can define permissions directly on the child that modify the effects of inherited permissions. For example, suppose a parent object has an inheritable ACE that denies access to Marketing. And suppose the owner of a child object defines an explicit ACE that allows access to a subset of Marketing, let's say Bob. If the child object's ACEs are in canonical order, the explicit ACE that allows Bob access comes before any inherited ACE, including the inherited ACE that denies access to Marketing. During an access check, the operating system reaches the ACE that allows Bob access before it gets to the ACE that denies access to Marketing. As a result, Bob is allowed access to the object even though he is a member of the Marketing group. Other members of the group are denied access.

What Happens When You Upgrade

When you upgrade a computer from Windows NT 4.0 to Windows 2000, the new canonical order is applied to DACLs on existing objects the first time after the upgrade that their security descriptors are modified. Because Windows 2000 introduces automatic propagation of ACEs to existing objects, the DACLs on all objects in the hierarchy below the modified object are also converted to the new canonical order. The security descriptors for objects that have been converted contain the security descriptor control flags SE_DACL_AUTO_INHERITED and SE_SACL_AUTO_INHERITED.

The operating system uses the following rules for propagating inherited ACEs to child objects.

No DACL vs Empty DACL

A security descriptor with no DACL gives unconditional access to everyone. A security descriptor with an empty DACL gives no access to anyone.

In Windows NT, if you were a developer who wanted to allow everyone unconditional access to an object, your code could create the object without a DACL. In Windows 2000, developers can still create objects with no DACL, but code that creates an object with no DACL must now set the SE_DACL_PROTECTED security descriptor control flag. If that flag is not set, the object will acquire a DACL through inheritance, and the result is likely to be something less than unconditional access for everyone. In fact, if the parent object has no inheritable permissions, the child could end up with an empty DACL—which would allow no access to anyone, exactly the opposite of what the object's creator intended.

If you are developing for Windows 2000 and want to give everyone unconditional access to an object that your code creates, then assign the object a DACL with one ACE that grants Everyone full control.


What Happens When You Convert FAT to NTFS

When you convert a FAT volume to the NTFS file system, Windows 2000 sets permissions on all folders and files in the converted volume. The permissions set on existing folders are shown in Table 12.13. The permissions set on existing files are shown in Table 12.14. All permissions are set in explicit ACEs.

Table 12.13 DACL on Existing Folders After Converting from FAT to NTFS

Type Name Permission Apply to
Allow System Full Control This folder only
Allow Administrators Full Control This folder only
Allow Everyone Full Control This folder, subfolders and files

Table 12.14 DACL on Existing Files After Converting from FAT to NTFS

Type Name Permission
Allow System Full Control
Allow Administrators Full Control
Allow Everyone Full Control

Only the last ACE in a folder's DACL is inheritable, so this is the only ACE that is inherited by new objects that are created in the converted volume. Table 12.15 shows the DACL for files and folders created after the conversion.

Table 12.15 DACL on New Files and Folders After the Conversion

Type Name Permission
Allow Everyone Full Control

This DACL would not be a problem on computers running Windows NT. However, it does pose a problem on computers running Windows 2000. For example, suppose you edit permissions on the converted volume's root, and you remove the inheritable permission that allows Everyone full control of the folder, subfolders, and files. In Windows 2000, changes to inheritable ACEs are propagated down the tree of objects; changes to inheritable ACEs on the root object in a tree are propagated to the entire tree. Objects that existed before the conversion have explicit ACEs allowing Everyone full control, not inheritable ACEs, so they would not be affected by the change in permissions on the root object. But files and folders created after the conversion have an inherited ACE allowing Everyone full control. This ACE would be removed from all files and folders created after the conversion, and each of these objects would end up with an empty DACL, which allows no access to anyone.

You could recover from this error by adding a new inheritable ACE to the root object and propagating that change down the tree of objects. However, it is always better to preclude the possibility of error rather than try to recover from one. In this case, you can avoid trouble by changing the non-inheritable ACEs on the root object to inheritable ACEs. It is recommended that you do this immediately after converting a volume from FAT to NTFS.

To avoid creating empty DACLs on a converted volume

  1. Open Windows Explorer, and then locate the drive symbol for the converted volume.
  2. Right-click the drive symbol, click Properties, click the Security tab, and then click Advanced.
  3. In Permissions, double-click Administrators.
  4. In Apply onto, select "This folder, subfolders and files."
  5. Click OK.
  6. In Permissions, double-click System.
  7. In Apply onto, select "This folder, subfolders and files."

  8. warning-icon

    Warning

    Do not check Reset permissions on all child objects and enable propagation of inheritable permissions. Propagation of inheritable permissions is already enabled by default. Checking this option clears the SE_DACL_PROTECTED security descriptor control flag in every child object's security descriptor and removes permissions that are explicitly defined on the objects. Neither action is necessary for this procedure.

  9. Click OK until all dialog boxes are closed.

After you make this change, the new inheritable ACEs are propagated to child objects below the root folder, and they are inherited by any new subfolders and files that are created in the tree.

© 1985-2000 Microsoft Corporation. All rights reserved.