Windows 10 file system access and privacy

Some apps need to access your file system to allow you to take full advantage of the functionality they provide. Allowing an app to have file system access enables it to have access to the same files and folders to which you have access. The app must request this access, and you can choose to allow or deny the request.

Allowing access to your file system might give apps access to personal content that you want to manage. This is why we give you control over the files you share by letting you choose which apps you’ll allow to access your file system. If you give an app permission but change your mind later, you can turn off that app’s access to your file system by going to Start > Settings > Privacy > File system.

Note: File system access might be turned off already if you’re using a device assigned to you by your workplace, or if you’ve added a work account to your personal device. If that’s the case, you’ll see a message telling you that “Some settings are managed by your organization” at the top of the File system settings page.

How the file system access settings work

To allow or block file system access for a specific app and service

Go to Start , and then select > Settings > Privacy > File system.

Make sure Allow apps to access your file system is turned On.

Under Choose which apps can access your file system, choose the individual apps and services for which you want to allow or block file system access and change the settings to On or Off.

To deny file system access for most apps

Go to Start , and then select > Settings > Privacy > File system.

Make sure Allow apps to access your file system is turned Off. This will prevent apps from accessing your file system on that device while you’re signed in to it. If other people share the same device, they can still turn on file system access when they’re signed in with their own accounts.

Exceptions to the file system access privacy settings

Not all apps will appear under Choose which apps can access your file system. Certain Windows programs, such as those that are downloaded from the internet or installed with some type of media (such as a CD, DVD, or USB storage device) won’t appear in that list and are not affected by the Allow apps access your file system setting. To allow or deny file system access for one of these programs, check the settings in the program itself.

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. For a detailed explanation of this model, see Access Control.

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, WRITE_OWNER, and SYNCHRONIZE standard access rights. The table in File Access Rights Constants lists the access rights that are specific to files and directories.

Although the SYNCHRONIZE access right is defined within the standard access rights list as the right to specify a file handle in one of the wait functions, when using asynchronous file I/O operations you should wait on the event handle contained in a properly configured OVERLAPPED structure rather than using the file handle with the SYNCHRONIZE access right for synchronization.

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

Access right	Description
FILE_GENERIC_EXECUTE	FILE_EXECUTE FILE_READ_ATTRIBUTES STANDARD_RIGHTS_EXECUTE SYNCHRONIZE
FILE_GENERIC_READ	FILE_READ_ATTRIBUTES FILE_READ_DATA FILE_READ_EA STANDARD_RIGHTS_READ SYNCHRONIZE
FILE_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. For more information about this process, see Interaction between Threads and Securable Objects.

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. For more information on file encryption, see File Encryption.

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:

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.

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.

Security descriptors in file systems

Windows file systems may support the storage and management of security descriptors associated with individual storage units within the file system. The granularity of security control is entirely up to the file system. For example, one file system might maintain a single security descriptor that covers everything on a given storage volume, while another might provide security descriptors that cover different parts of a single given file. The models that most developers are comfortable with are those provided by the existing Windows file systems:

NTFS supports a per-file (or directory) security descriptor model. NTFS is efficient in its storage of security descriptors, storing only a single copy of each security descriptor, even if it is used by many different files.

FAT, CDFS, UDFS do not support security descriptors.

RDBSS and the SMB Network Redirector provide support comparable to that provided by the remote volume.

These file systems, however, do not represent all possible implementations of Windows security for file systems.

A Windows security descriptor consists of four distinct pieces:

The security identifier (SID) of the owner of the object. An object’s owner always has the ability to reset the security on the object. This is a good way to ensure that, for example, all access to an object can be removed. Because even if owners remove their ability to perform all operations, this inherent right allows them to restore their security rights on the object.

An optional security identifier (SID) of the default group of the object. The concept of group ownership is one that is not required in Windows, but is useful for some applications.

The system access control list (SACL) that describes the auditing policy of the security descriptor.

The discretionary access control list (DACL) that describes the access policy of the security descriptor.

The following figure illustrates a windows security descriptor.

Security descriptors are variable-sized objects, with each of the individual sub-components being variable in size as well. To facilitate offline storage of security descriptors, a security descriptor may be in self-relative format, in which case the header is the offset within the buffer to the specific component of the security descriptor. An in-memory format consists of pointer values to the various parts of the security descriptor. For a file system, the self-relative format is normally the most useful because it allows for simple storage and retrieval of the security descriptor from persistent storage. Applications that build security descriptors are more likely to use the in-memory format. The security reference monitor provides conversion routines to convert from one format to the other.

This section includes the following topics:

Error Applying Security Access is Denied as an Administrator on File Object

I am getting access denied whenever I try to delete or rename a file. I am logged as id Administrator

BG: I was running ScanSoft PDF Professional and appending to an existing file. The program died and now I cannot delete, rename, or open the file.

I’ve tried the fixes on the forum; change owner of the file via folder security ownership properties, and the cmd line as Administrator «Takeown /f» described in another forum article, but none of the solutions work.

run cmd as administrator:

takeown /f drive:\path /r /d y

on the folder, I get a now owned message

But if I go to delete the file, I still get an access denied. I tried taking ownership specifically on the filename

takeown /f drive:\path\filename

I get an ERROR: Access is denied. message

When I examine the file’s Properties-Security-Owner I see that the Current owner is: Unable to display current owner

I tried taking ownership of the file through explorer and get a Windows Security Access is denied.

I’ve tried taking ownership of the folder with the Replace owner on subcontainers and objects and get an Error Applying Security . Access is denied.

I am running out of ideas.