The Windows File Management 13

 

 

 

 

 

File Security and Access Rights

 

Because files are securable objects, access to them is regulated by the access-control model that governs access to all other securable objects in Windows. You can specify a security descriptor for a file or directory when you call the CreateFile(), CreateDirectory(), or CreateDirectoryEx() function. If you specify NULL for the lpSecurityAttributes parameter, the file or directory gets a default security descriptor. The access control lists (ACL) in the default security descriptor for a file or directory are inherited from its parent directory. Note that a default security descriptor is assigned only when a file or directory is newly created, and not when it is renamed or moved. To retrieve the security descriptor of a file or directory object, call the GetNamedSecurityInfo() or GetSecurityInfo() function. To change the security descriptor of a file or directory object, call the SetNamedSecurityInfo() or SetSecurityInfo() function. The valid access rights for files and directories include the DELETE, READ_CONTROL, WRITE_DAC, and WRITE_OWNER standard access rights. The following table lists the access rights that are specific to files and directories.

 

Access right

Value

Description

FILE_ADD_FILE

0x0002

For a directory, the right to create a file in the directory.

FILE_ADD_SUBDIRECTORY

0x0004

For a directory, the right to create a subdirectory.

FILE_ALL_ACCESS

 

All possible access rights for a file.

FILE_APPEND_DATA

0x0004

For a file object, the right to append data to the file. (For local files, write operations will not overwrite existing data if this flag is specified without FILE_WRITE_DATA.) For a directory object, the right to create a subdirectory (FILE_ADD_SUBDIRECTORY).

FILE_CREATE_PIPE_INSTANCE

0x0004

For a named pipe, the right to create a pipe.

FILE_DELETE_CHILD

0x0040

For a directory, the right to delete a directory and all the files it contains, including read-only files.

FILE_EXECUTE

0x0020

For a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter.

FILE_LIST_DIRECTORY

0x0001

For a directory, the right to list the contents of the directory.

FILE_READ_ATTRIBUTES

0x0080

The right to read file attributes.

FILE_READ_DATA

0x0001

For a file object, the right to read the corresponding file data. For a directory object, the right to read the corresponding directory data.

FILE_READ_EA

0x0008

The right to read extended file attributes.

FILE_TRAVERSE

0x0020

For a directory, the right to traverse the directory. By default, users are assigned the BYPASS_TRAVERSE_CHECKING privilege, which ignores the FILE_TRAVERSE access right.

FILE_WRITE_ATTRIBUTES

0x0100

The right to write file attributes.

FILE_WRITE_DATA

0x0002

For a file object, the right to write data to the file. For a directory object, the right to create a file in the directory (FILE_ADD_FILE).

FILE_WRITE_EA

0x0010

The right to write extended file attributes.

STANDARD_RIGHTS_READ

 

Includes READ_CONTROL, which is the right to read the information in the file or directory object's security descriptor. This does not include the information in the SACL.

STANDARD_RIGHTS_WRITE

 

Same as STANDARD_RIGHTS_READ.

SYNCHRONIZE

 

The right to specify a file handle in one of the wait functions. However, for asynchronous file I/O operations, you should wait on the event handle in an OVERLAPPED structure rather than using the file handle for synchronization.

 

The following are the generic access rights for files and directories.

 

Access right

Description

GENERIC_EXECUTE

FILE_READ_ATTRIBUTES

STANDARD_RIGHTS_EXECUTE

SYNCHRONIZE

GENERIC_READ

FILE_READ_ATTRIBUTES

FILE_READ_DATA

FILE_READ_EA

STANDARD_RIGHTS_READ

SYNCHRONIZE

GENERIC_WRITE

FILE_APPEND_DATA

FILE_WRITE_ATTRIBUTES

FILE_WRITE_DATA

FILE_WRITE_EA

STANDARD_RIGHTS_WRITE

SYNCHRONIZE

 

Windows compares the requested access rights and the information in the thread's access token with the information in the file or directory object's security descriptor. If the comparison does not prohibit all of the requested access rights from being granted, a handle to the object is returned to the thread and the access rights are granted. By default, authorization for access to a file or directory is controlled strictly by the ACLs in the security descriptor associated with that file or directory. In particular, the security descriptor of a parent directory is not used to control access to any child file or directory. The FILE_TRAVERSE access right can be enforced by removing the BYPASS_TRAVERSE_CHECKING privilege from users. This is not recommended in the general case, as many programs do not correctly handle directory traversal errors. The primary use for the FILE_TRAVERSE access right on directories is to enable conformance to certain IEEE and ISO POSIX standards when interoperability with Unix systems is a requirement.

The Windows security model provides a way for a child directory to inherit, or to be prevented from inheriting, one or more of the ACEs in the parent directory's security descriptor. Each ACE contains information that determines how it can be inherited, and whether it will have an effect on the inheriting directory object. For example, some inherited ACEs control access to the inherited directory object, and these are called effective ACEs. All other ACEs are called inherit-only ACEs. The Windows security model also enforces the automatic inheritance of ACEs to child objects according to the ACE inheritance rules. This automatic inheritance, along with the inheritance information in each ACE, determines how security restrictions are passed down the directory hierarchy.

Note that you cannot use an access-denied ACE to deny only GENERIC_READ or only GENERIC_WRITE access to a file. This is because for file objects, the generic mappings for both GENERIC_READ or GENERIC_WRITE include the SYNCHRONIZE access right. If an ACE denies GENERIC_WRITE access to a trustee, and the trustee requests GENERIC_READ access, the request will fail because the request implicitly includes SYNCHRONIZE access which is implicitly denied by the ACE, and vice versa. Instead of using access-denied ACEs, use access-allowed ACEs to explicitly allow the permitted access rights. Another means of managing access to storage objects is encryption. The implementation of file system encryption in Windows is the Encrypted File System, or EFS. EFS encrypts only files and not directories. The advantage of encryption is that it provides additional protection to files that is applied on the media and not through the file system and the standard Windows access control architecture.

In most cases, the ability to read and write the security settings of a file or directory object is restricted to kernel-mode processes. Clearly, you would not want any user process to be able to change the ownership or access restriction on your private file or directory. However, a backup application would not be able to complete its job of backing up your file if the access restrictions you have placed on your file or directory does not allow the application's user-mode process to read it. Backup applications must be able to override the security settings of file and directory objects to ensure a complete backup. Similarly, if a backup application attempts to write a backup copy of your file over the disk-resident copy, and you explicitly deny write privileges to the backup application process, the restore operation cannot complete. In this case also, the backup application must be able to override the access control settings of your file.

The SE_BACKUP_NAME and SE_RESTORE_NAME access privileges were specifically created to provide this ability to backup applications. If these privileges have been granted and enabled in the access token of the backup application process, it can then call CreateFile() to open your file or directory for backup, specifying the standard READ_CONTROL access right as the value of the dwDesiredAccess parameter. However, to identify the calling process as a backup process, the call to CreateFile() must include the FILE_FLAG_BACKUP_SEMANTICS flag in the dwFlagsAndAttributes parameter. The full syntax of the function call is the following:

 

HANDLE hFile = CreateFile(

                 fileName,                   // lpFileName

                 READ_CONTROL,  // dwDesiredAccess

                 0,                                // dwShareMode

                 NULL,                        // lpSecurityAttributes

                 OPEN_EXISTING,              // dwCreationDisposition

                 FILE_FLAG_BACKUP_SEMANTICS, // dwFlagsAndAttributes

                 NULL                        // hTemplateFile

               );

 

This will allow the backup application process to open your file and override the standard security checking. To restore your file, the backup application would use the following CreateFile() call syntax when opening your file to be written.

 

HANDLE hFile = CreateFile( fileName,         // lpFileName

                 WRITE_OWNER|WRITE_DAC,     // dwDesiredAccess

                 0,                               // dwShareMode

                 NULL,                       // lpSecurityAttributes

                 CREATE_ALWAYS,              // dwCreationDisposition

                 FILE_FLAG_BACKUP_SEMANTICS, // dwFlagsAndAttributes

                 NULL                        // hTemplateFile

              );

 

There are situations when a backup application must be able to change the access control settings of a file or directory. An example is when the access control settings of the disk-resident copy of a file or directory is different from the backup copy. This would happen if these settings were changed after the file or directory was backed up, or if it was corrupted. The FILE_FLAG_BACKUP_SEMANTICS flag specified in the call to CreateFile() gives the backup application process permission to read the access-control settings of the file or directory. With this permission, the backup application process can then call GetKernelObjectSecurity() and SetKernelObjectSecurity() to read and than reset the access-control settings. If a backup application must have access to the system-level access control settings, the ACCESS_SYSTEM_SECURITY flag must be specified in the dwDesiredAccess parameter value passed to CreateFile(). Backup applications call BackupRead() to read the files and directories specified for the restore operation, and BackupWrite() to write them.

 

 

 

 

< Windows Files 12 | Win32 Programming | Win32 File Index | Windows Files 14 >