Article ID: 150101
Article Last Modified on 11/21/2006
APPLIES TO
- Microsoft Win32 Application Programming Interface, when used with:
- Microsoft Windows 2000 Standard Edition
- Microsoft Windows NT 3.51 Service Pack 5
- Microsoft Windows XP Professional
This article was previously published under Q150101
SUMMARY
This article describes how volume-level security behaves, and how it
differs from the file- and directory-level security provided by the New
Technology File System (NTFS).
Microsoft Windows 2000, Windows NT, Windows XP provides auditing and access control facilities for physical and logical volumes. Conceptually, volume-level security is designed to control volume-level access, such as formatting operations, rather than file- and directory-level operations. Volume-level security also minimally protects logical volumes that are not formatted with NTFS, such as floppy disks and compact discs.
MORE INFORMATION
Windows 2000, Windows NT, or Windows XP were designed to have security descriptors applied to volumes control and audit volume-level access such as formatting a disk or reading raw disk sectors. The file system with which the logical volume is formatted is responsible for control and auditing of access to files and directories. Currently, the only file system to support file- and directory-based security is NTFS.
There are two types of volume-level operations that need to be understood:
physical drive access and logical volume access. Physical drive access
allows Win32-based applications to manage hard disk partition tables and
logical volumes. Logical volume access allows Win32-based applications to
manage the contents of a partition below the file system level. Logical
volume access is most often used to format a partition with a particular
file system, such as FAT or NTFS. The following sections explain how volume-level security applies to each type of volume-level access.
Physical Drive Security
Win32-based applications can open handles to physical hard disk drives for
low-level access by calling CreateFile() with \\.\PHYSICALDRIVEx, where x
is the zero-based physical drive number. Once the applications have a
handle, they can use DeviceIoControl() to call IOCTL functions, or
ReadFile() and WriteFile() to perform sector reads and writes.
Access to physical drives is a built-in right of the Administrators group
and does not need to be enabled. Users who are not members of the
Administrators group cannot open physical drives under any circumstances.
Although any member of the Administrators group can enable access control
and auditing on physical drives, doing so provides little value for two
reasons, the first leading to the second:
- Adding access control lists (ACLs) to a physical drive does not control or audit access to the logical volumes on the drive, or to files and directories within those logical volumes. Instead, the ACLs are used to control and audit access to the physical drive itself, such as opening the physical drive with CreateFile() using \\.\PHYSICALDRIVEx.
- Because only members of the Administrators group can access physical drives, the only use for an ACL on a physical drive is to control or audit the access that they have. Because members can change the ACLs on physical drives, their access is not truly limited.
Finally, the ACLs applied to physical drives are in effect only until the
system is shut down or restarted.
Logical Volume Security
Win32-based applications can open logical volumes with CreateFile() by
specifying the file name as \\.\X:, where X is the actual drive letter.
Once this is done, the applications can use the handle to issue IOCTL
functions or read and write raw sectors.
Specifying access control on a logical volume controls access to the
logical volume itself and to all of the files and directories contained by
the volume allows Windows NT to provide a basic level of security to media
that is not formatted with NTFS, such as floppy disks, compact discs, and
hard disk partitions formatted with the FAT file system.
Access controls applied to removable media affect access to the drive, not
just to the media that was in the drive when the drive was secured. For
example, if users are prevented from accessing A:\, they are not able to
use drive A:, no matter which floppy disk is inserted.
Although access control protects a logical volume and all of its contents,
auditing only records accesses to the volume itself. Accesses to files and
directories within the volume are not recorded. This is analogous to the
way NTFS audits directories; only access to the directory itself is
audited. Thus, opening a logical volume by specifying \\.\X: as a file name
to CreateFile(), causes an entry to be placed in the security event log
while opening a file on the same volume does not.
Auditing and access control apply to logical volumes only as long as the
system is running. If you want to control access to or audit logical
volumes after the machine has been restarted, you must reapply the
security.
How to Enable Volume-Level Security
Access control and auditing are enabled by placing access control lists
(ACLs) on the volume. The discretionary ACL (DACL) provides access control
information, while the system ACL (SACL) provides auditing. To apply ACLs
to a volume, create a security descriptor with the desired ACLs, and then
use SetFileSecurity() to apply it. SetFileSecurity() can be used on both
physical and logical volumes and in addition to files and directories, as
follows:
- Physical volumes must be specified as a string in the form \\.\PHYSICALDRIVEx, where x is the zero-based drive number.
- Logical volumes must be specified as a string in the form \\.\x:, where x is the actual drive letter of the volume.
Additional query words: 3.50 3.51 4.00 NTFS CD-ROM
Keywords: kbinfo kbapi kbkernbase kbsecurity kbfileio KB150101