All named objects in Windows NT and some unnamed objects can be secured. A security descriptor describes the security attributes for an object. An object's security descriptor includes four parts:
For details and background information about security in Windows NT 4.0, see Chapter 6, "Windows NT Security," in the Microsoft Windows NT Workstation Resource Guide.
The permissions that can be granted or denied for an object depends on the type of object. For example, you can specify permissions, such as Manage Documents and Print for a printer queue, and specify Read, Write, Execute for a directory.
Permissions of an object are also affected by whether that object is a container object or a noncontainer object. A container object is one that logically contains other objects; a noncontainer object does not contain other objects. For example, a directory is a container object that logically contains files and other directories. Files are noncontainer objects. This distinction between container and noncontainer objects is important because objects within a container object can inherit certain permissions from the parent container.
Note
NTFS supports ACL inheritance from directory objects to file objects that are created within the directory. For more information about NTFS, see "Disk and File System Basics" and "Choosing a File System" in the Microsoft Windows NT Workstation Resource Guide.
Each ACL is made up of access control entries (ACEs), which specify access or auditing permissions to that object for one user or group. There are three ACE types: two for discretionary access control and one for system security.
The discretionary ACEs are AccessAllowed and AccessDenied. These explicitly grant and deny access to a user or group of users. The first AccessDenied ACE denies the user access to the resource, and no further processing of ACEs occurs.
Note
There is an important distinction between a discretionary ACL that is empty (one that has no ACEs in it) and an object without any discretionary ACL. In the case of an empty discretionary ACL, no accesses are explicitly granted, so access is implicitly denied. For an object that has no ACL at all, there is no protection assigned to the object, so any access request is granted.
SystemAudit is a system security ACE that is used to keep a log of security events (such as who accesses which files) and to generate and log security audit messages.
Each ACE includes an access mask, which defines all possible actions for a particular object type. An access mask can be compared to a menu, from which you select permissions to grant or deny.
Specific types include access options that apply specifically to an object type. Each object type can have up to 16 specific access types. Collectively, the specific access types for a particular object type are called the specific access mask. These are defined when the object type is defined.
For example, Windows NT files have the following specific access types:
Standard types apply to all objects and consist of these access permissions:
Generic types are broad types of access used when protecting an object. Exact implementation of these is determined by the application defining an object. For example, an application that defines a voice-annotation object might define specific access rights by using VOICE_PLAY and VOICE_EDIT for playing and editing the object. It might set up a generic mapping structure in which GENERIC_EXECUTE maps to VOICE_PLAY and GENERIC_WRITE maps to both VOICE_PLAY and VOICE_EDIT.
The following table shows the generic types that are mapped from specific and standard types.
Table 2.3 Generic types of access masks
Generic type | Mapped from these specific and standard types | |
FILE_GENERIC_READ | STANDARD_RIGHTS_READ | |
FILE_GENERIC_WRITE | STANDARD_RIGHTS_WRITE | |
FILE_GENERIC_EXECUTE | STANDARD_RIGHTS_EXECUTE | |
Specific and standard types appear in the details of the security log. Generic types do not appear in the security log. Instead, the corresponding specific and standard types are listed.
When you create new objects within a container object, the new objects inherit permissions by default from the parent object.
In the case of files and directories, changing the permissions on a directory affects that directory and its files but does not automatically apply to existing subdirectories and their contents. They will do so if you select the Replace Permissions On Existing Files check box and the Replace Permissions On Subdirectories check box in the Directory Permissions dialog box.