Securing File and Folder Permissions

All file and folder objects stored on an NTFS volume have security descriptors to control access to the object. The security descriptor includes a discretionary access control list (DACL) and a system access control list (SACL), in addition to information that identifies the object s owner. Figure 7-1 shows the contents of a security descriptor.

figure 7-1 contents of a security descriptor

Figure 7-1. Contents of a security descriptor

DACLs owe their name to the fact that they can be configured at the discretion of any account that possesses Take Ownership, Change Permissions, or Full Control permissions to the file system object. DACLs consist of several elements, which are described in Table 7-1 and shown in Figure 7-2.

Table 7-1. Elements of a DACL
Element	Description
Header	Metadata pertaining to the access control entries (ACEs) associated with the DACL.
SID (user)	The security identifier (SID) of the owner of the object.
SID (group)	The SID of the built-in Administrators or Domain Admins group if the account that owns the object is a member of either group.
Generic deny ACEs	ACEs that deny access to an account or security group based on that group s SIDs. These ACEs can be inherited from the object s parent or assigned directly to the object.
Generic allow ACEs	ACEs that allow access to child objects to an account or security group based on that group s SIDs. These ACEs can be inherited from the object s parent or assigned directly to the object.

figure 7-2 composition of a dacl

Figure 7-2. Composition of a DACL

You can see the ACEs for files and folders, as well as other types of objects, by using Subinacl.exe. Type subinacl /verbose=2 /objecttypeobjectname, where objecttype is the type of object and objectname is the name of the object.

What Does Owning a Resource Mean?

The owner of a resource, such as a file or folder, is the account that ultimately determines the access control over a resource. The owner has complete control over the resource, including the ability to assign permissions to other accounts. Even if the owner is explicitly denied access to a resource, the owner changes the permissions on the resource to restore her access. File ownership is also used by the quota system in Windows 2000 and Windows XP to calculate the amount of disk space used by each tracked account, if disk quotas are enabled. The default owner of files and folders in Windows 2000 and Windows XP installations is the built-in Administrators group, although a user who creates a file or folder is the owner of anything she creates.

Members of the Administrators group can always take ownership of files and folders on the local computer even if NTFS permissions prohibit administrators from accessing the resource. This ensures that files can be recovered by an administrator in the event that a user leaves the company or permissions are incorrectly configured and must be corrected. When a member of the Administrators group takes ownership of a resource, the ownership is granted to the Administrators group. However, the SID of the individual administrator is also recorded and stored in the DACL for accountability reasons. When a user who is not a member of the Administrators group takes ownership of a resource, ownership is associated with her account s SID.

Although the user interface prevents you from assigning ownership of an object to another user account, you can complete this action from the command line if you are a member of the Administrators group on the computer using the command-line tool Subinacl.exe. The syntax for replacing the owner of a file using Subinacl.exe follows:

Subinacl /onlyfile filename.ext /setowner=domain\newowner

You can use Subinacl.exe to configure permissions on:

Files
Folders
Registry keys
Services
Printers
Kernel objects
Shares
Metabases

Subinacl.exe is a low-level utility and should be used with caution. For routine permission changes on files and folders, other tools such as Xcacls.exe and Cacls.exe are easier to use.

You can define NTFS permissions at either the folder or file level. For folders, you can assign the following standard permissions in the Security tab of the folder s Properties dialog box:

Full Control
Modify
Read & Execute
List Folder Contents
Read
Write

For individual files, these are the standard permissions:

Full Control
Modify
Read & Execute
Read
Write

Standard NTFS permissions are compilations of several special permissions, including these:

Traverse Folder/Execute File
Traverse Folder allows or denies navigating through folders, even though the user does not have permissions to access files or folders within that folder. This permission applies to folders only. Execute File allows or denies running program files and applies to files only. Setting the Traverse Folder permission will not automatically set the Execute File permission on the files in the folder. Additionally, by default the Everyone group is assigned the Bypass Traverse Checking user right, which prevents the Traverse Folder permissions from being assessed when a resource is accessed.
List Folder/Read Data
List Folder allows or denies viewing file names and subfolder names within the folder and applies to folders only. Read Data allows or denies viewing data in files and applies to files only.
Read Attributes
Allows or denies viewing the attributes of a file or folder, such as Read-Only and Hidden attributes.
Read Extended Attributes
Allows or denies viewing the extended attributes of a file or folder. Specific programs define the extended attributes.
Create Files/Write Data
Create Files allows or denies creating files within a folder. Write Data allows or denies making changes to a file and overwriting existing content.
Create Folders/Append Data
Create Folders allows or denies creating folders within a folder. Append Data allows or denies making changes to the end of the file but not changing, deleting, or overwriting any existing data in the file.
Write Attributes
Allows or denies changing the attributes of a file or folder, such as Read-Only and Hidden attributes.
Write Extended Attributes
Allows or denies viewing the extended attributes of a file or folder. The extended attributes are defined by specific programs.
Delete Subfolders and Files
Allows or denies deleting subfolders and files when applied at a parent folder, even if the Delete permission has not been granted on the specific subfolder or file.
Delete
Allows or denies the deletion of a file or folder.
Read Permissions
Allows or denies reading permissions assigned to a file or folder.
Change Permissions
Allows or denies modification of the permissions assigned to a file or folder.
Take Ownership
Allows or denies taking ownership of the file or folder.

Table 7-2 displays how, in Windows 2000, the special permissions map to the basic permissions.

Table 7-2. File and Folder Permissions Mapping in Windows 2000
	Basic Permissions
Special Permissions	Full Control	Modify	Read & Execute	List Folder Contents (Permissions apply to folder objects only)	Read	Write
Traverse Folder/Execute File	X	X	X	X
List Folder/Read Data	X	X	X	X	X
Read Attributes	X	X	X	X	X
Read Extended Attributes	X	X	X	X	X
Create Files/Write Data	X	X				X
Create Folders/Append Data	X	X				X
Write Attributes	X	X				X
Write Extended Attributes	X	X				X
Delete Subfolders and Files	X
Delete	X	X
Read Permissions	X	X	X	X	X	X
Change Permissions	X
Take Ownership	X

How DACLs Work

When a user attempts to access a file or folder on an NTFS partition, the user s access token is compared with the DACL of the file or folder. If no ACEs correspond to a SID in the user s access token, the user is implicitly denied access to the resource. If ACEs correspond to the user s access token, the ACEs are applied in the following order:

Explicit deny
An ACE applied directly to the resource that denies access. An explicit deny will always override all other permissions.
Explicit allow
An ACE applied directly to the resource that grants access. An explicit allow will always override an inherited deny but will always be overridden by explicit deny ACEs.
Inherited deny
An ACE inherited from the resource s parent object. An inherited deny ACE will override an inherited allow permission but will be overridden by an explicit allow.
Inherited allow
An ACE inherited from the resource s parent object.

ACEs that apply to the user are cumulative, meaning that the user will receive the sum of the ACEs that apply to his user account and groups of which he is a member. For example, if an access control list (ACL) contains two allow ACEs that apply to the user, one for Read access and the other for Write access, the user will receive Read and Write access.

Because explicit allow ACEs override inherited deny ACEs, you should assign explicit permissions with caution. For example, if the Sales_Managers group has been denied the Write permission on all file and folders in the d:\finance_audit folder but a user named Tom is granted Write permissions to the d:\finance_audit\review\Excel1.xls file, Tom will be able to modify the Excel1.xls file even if he is a member of the Sales_Managers group, which is denied Write permissions by inheritance.

Assigning DACLs at Creation

When a file or folder is created, it inherits from its parent object the permissions that are applicable to its type of object. This includes both permissions that are inherited by the parent object and permissions that are explicitly assigned to the parent object. Once created, you can augment the inherited permissions by adding ACEs to the newly created resource.

In Windows 2000 and Windows XP, each file and folder has a property enabled by default that stipulates that the object will Allow Inheritable Permissions From The Parent Object To Propagate To This Object. By default, if you alter the permissions on the parent object, the permission change will automatically flow to the child object. If you want to modify this behavior, you need to decide whether you want to remove the inherited permissions or copy them to the object. If you choose to remove the inherited permissions, the only permissions that will remain are those explicitly granted to the object. If you choose to copy the permissions, the object will have the same permissions as it had previously, but the formerly inherited permissions will instead be explicitly assigned to the object.

In the Windows 2000 and Windows XP user interfaces, explicit permissions are displayed with a check in a white check box and inherited permissions are displayed with a check in a gray check box. Gray check boxes cannot be directly modified unless the permissions are made explicit, which changes the check boxes to white to indicate explicit assignment.

How DACLs Are Handled When Files and Folders Are Copied or Moved

The way DACLs are handled for files and folders that are moved and copied into other locations can be confusing. If you are responsible for securing files and folders, you must understand several intricacies of copying and moving files and folders, or you might unwittingly create a security risk.

The first thing you need to know is that creating a copy of a file on the same partition actually creates a new file in the destination container. Thus, all permissions are inherited from the new parent object. The original object s permissions are unchanged. This action creates a potential security risk because two copies of the same file that have different security settings can exist.

Second, when a file is moved on the same partition, it is not physically relocated to a different address on the disk instead, the reference to the object in the file system hierarchy is updated. When the ACL on a parent object or an object itself is changed, the permissions structures are updated, but moving an object on the same partition does not trigger a refresh of ACLs. Therefore, all previously inherited and explicit permissions on the moved object initially remain unchanged. The Security tab for the object will indicate that the permissions are inherited from its parent object, but until the ACL is refreshed, the Security tab shows inherited permissions from the object s previous parent, along with any permissions assigned directly to the object. The next time that the ACLs for the object itself or for any parent object in the inheritance hierarchy are changed, the inherited permissions on the object will be received from the object s new location in the file system hierarchy. However, the moved object will retain any explicitly assigned permission.

This behavior is a departure from the way that permissions on moved file system objects functioned in Windows NT, where objects that were moved within the same partition retained all permissions. If you want to achieve Windows NT style retention of all permissions on an object you move within the same partition, before moving the object, you must deselect the inheritance attribute on the object and copy the existing inherited permissions so that they become explicit permissions. Or you must remove existing inherited permissions altogether and assign any desired explicit permissions. You can then move the object and reenable permissions inheritance, which will refresh the ACL on the object. When the ACL is refreshed in this manner, the moved object will retain its explicit permissions but will receive new inherited permissions from its new parent.

Finally, when you move a file or folder to a different partition or computer, the operation is actually a copy-and-delete process. The file is copied in the new location, thus creating a new file system object, and upon successful creation of the new object, the original is deleted. Creating a copy of a file system object regardless of whether the copy is created on the same partition or on a different partition or computer always creates a new instance of the object in the destination location. Therefore, all permissions on the object are inherited from the new parent. Original copies of the object are either deleted (in a move operation across partitions or computers) or unaffected (in a copy operation). Therefore, you should exercise caution when moving or copying files and folders to different partitions or computers. This is because the permissions on the newly created object might not be consistent with the permissions on the original object.

Command-Line Tools

In Windows 2000 and Windows XP, the Xcopy.exe command can be used to preserve the permissions and ownership of file and folders when they are copied. Additionally, you can use several command-line tools to control the file and folder permissions:

Cacls.exe
Xcacls.exe
Subinacl.exe
Robocopy.exe

Robocopy.exe, Xcacls.exe, and Subinacl.exe are located in the Tools folder on the CD included with this book. Cacls.exe is included in the default installation of Windows 2000 and Windows XP.

Cacls.exe

Cacls.exe is a command-line utility that enables basic management of file and folder permissions. The usage for Cacls.exe follows:

CACLS filename [/T] [/E] [/C] [/G user:perm] [/R user [...]] [/P user:perm [...]] [/D user [...]]

Table 7-3 shows the command-line options for Cacls.exe. You can also use wildcard characters to specify more than one file in a command.

Table 7-3. Command-Line Options for Cacls.exe
Option	Description
filename	Placeholder for the name of the file. Running Cacls.exe with just the file name will display the DACL of the file or folder.
/T	Changes DACLs of specified files in the current directory and all subdirectories.
/E	Edits the existing DACL instead of replacing it.
/C	Continues processing even if an access denied error occurs.
/G user:perm	Grants the specified user access rights to the file or folder using explicit permissions.
user	Domain and user name that you are modifying permissions for. You can specify more than one user in a command.
perm	R for Read, W for Write, C for Change (Write), F for Full Control, N for None.
/R user	Revokes all the specified user s access rights (valid only with /E).
/P user:perm	Replaces the specified user s access rights.
/D user	Denies the specified user access to the file or folder.

You can redirect console output from the command line by using a standard redirection character. For example, to redirect output from the Cacls.exe tool to a file, type Calcs.exe filename.ext>output.txt. The results of running the command will be written to the Output.txt file rather than to the console.

Xcacls.exe

Xcacls.exe is a more robust version of Cacls.exe. Not only does Xcacls.exe give you greater control over the special permissions, it is scriptable: unlike Cacls.exe, Xcacls.exe allows you to suppress message prompts. The usage for Xcacls.exe follows:

xcacls filename [/T] [/E] [/C] [/G user:perm;spec] [/R user] [/P user:perm;spec [...]] [/D user [...]] [/Y]

Table 7-4 shows the command-line options for Xcacls.exe.

Table 7-4. Command-Line Options for Xcacls.exe
Option	Description
filename	Placeholder for the name of the file. Running Xcacls.exe with just the file name will display the DACL of the file or folder.
/T	Recursively walks through the current directory and all its subdirectories, applying the chosen access rights to the matching files or directories.
/E	Edits the existing DACL instead of replacing it.
/C	Causes Xcacls.exe to continue if an access denied error occurs.
/G user:perm;spec	Grants access to the user to the matching file or directory. The perm variable applies the specified access right to files.
perm	R for Read, C for Change (Write), F for Full Control, P for Change Permissions, O for Take Ownership, X for Execute, E for Read, W for Write, D for Delete.
/R user	Revokes all access rights for the specified user.
/P user:perm;spec	Replaces access rights for the user.
/D user	Denies the user access to the file or directory.
/Y	Disables confirmation when replacing user access rights. By default, Xcacls.exe prompts for confirmation, and when used in a batch routine, causes the routine to stop responding until the confirmation is entered. The /Y option was introduced to avoid this confirmation so that Xcacls.exe can be used in batch mode.

Xcacls.exe is located in the Tools folder of the CD that is included with this book. Xcacls.vbs, a Microsoft Visual Basic script, is also included on the CD in the Tools\Scripts\XCACLS VBS folder. You can use Xcacls.vbs to assign permissions in a similar way that you do with Xcacls.exe, albeit from a script. Xcacls.exe is designed to be used at the command-line or in batch files; Xcacls.vbs is designed to be used in a scripting environment, where better automation and error handling are required. In addition, you can edit Xcacls.vbs by using any text editor to add custom functionality, such as logging permission changes to a file.

Subinacl.exe

Subinacl.exe is a low-level utility for managing DACLs on many types of objects, including files and folders. The syntax for using Subinacl.exe follows:

subinacl [view_mode] [/test_mode] object_typeobject_name [action[=parameter]] [action[=parameter]] ... [/playfile file_name] [/help [/full] [keyword]]

The options you can use with Subinacl.exe are explained in Table 7-5.

Table 7-5. Command-Line Options for Subinacl.exe
Option	Description
view_mode	Defines the level of detail in the output of Subinacl.exe. You can use the following switches with this option: /noverbose /verbose (defaults to /verbose=2) /verbose=1 /verbose=2
/test_mode	When this option is specified, changes are not actually made to the object s security descriptor. This option enables you to view what the results of the command would be without actually making the changes.
object_type	Specifies the type of object on which you are modifying the permissions. You can use these types of objects: /file /subdirectories /onlyfile /share /clustershare /keyreg /subkeyreg /service /printer /kernelobject
object_name	Defines the name of an object on which you are viewing or modifying the permissions.
Action	Sets the action that you are attempting to carry out on the object. The Action switches include: /display (default) /setowner=owner /replace=[DomainName\]OldAccount=[DomainName\]NewAccount /changedomain=OldDomainName=NewDomainName /migratetodomain=SourceDomain=DestDomain /findsid=[DomainName\]Account[=stop] /suppresssid=[DomainName\]Account /confirm /perm /audit /ifchangecontinue /cleandeletedsidsfrom=DomainName /accesscheck=[DomainName\]UserName /setprimarygroup=[DomainName\]Group /grant=[DomainName\]UserName[=Access] /deny=[ DomainName\]UserName[=Access] /revoke=[DomainName\]UserName /playfile filename

Robocopy.exe

Robocopy.exe is a 32-bit Windows command-line application that simplifies the task of maintaining an identical copy of a folder tree in multiple locations, either on the same computer or in separate network locations. Robocopy is robust it retries operations after network errors and efficiently copies only changed files. Robocopy is flexible you can copy a single folder or walk a directory tree, specifying multiple file names and wildcard characters for source files. For detailed information on using Robocopy, see the Robocopy.doc file on the CD included with this book.

Default File and Folder Permissions

In Windows 2000 and Windows XP, file and folder permissions are automatically inherited from their parent objects. Therefore, understanding the default permission on files and folders is important in planning directory structures. You might need to change the default permissions to meet your organization s security policy. Table 7-6 provides a legend to the various Windows 2000, Windows XP, and Windows NT default permissions.

Table 7-6. Default Permissions Legend
Abbreviation	Description
CI (Container Inherit)	The ACE will be applied to the current directory and inherited by subdirectories.
OI (Object Inherit)	The ACE will be applied to files in the directory and inherited by files in subdirectories.
IO (Inherit Only)	The ACE will not be applied to the current folder or file but will be inherited by child folders.
NI (Not Inherited)	The ACE is not propagated to any child objects.

Recommended Permissions for Windows 2000 and Windows XP

In Windows 2000 and Windows XP the default permissions on files and folders are configured during setup when you choose to format a partition with NTFS. Unfortunately, for most organizations, the default permissions do not provide enough security for information stored on the computer. Table 7-7 contains the recommended permissions for files and folders in Windows 2000 and Windows XP. Unless otherwise stated, the permissions listed in the table apply to the folder mentioned in the leftmost column, as well as all of its subfolders and files.

The security template MWSRK_NTFS.inf is located in the Tools\Template folder on the CD included with this book. You can use this template on computers with Windows 2000 and Windows XP newly installed to configure the permissions listed in Table 7-7. Applying this template to an existing installation could cause applications to cease to function.

Table 7-7. Recommended Permissions for Windows 2000 and Windows XP
File/Folder	Administrators	System	Creator Owner	Users	Power Users
%programfiles%	Full Control	Full Control	Full Control (subfolders and files only)	Read & Execute, List Folder Contents, Read	Modify
%system drive%\ IO.SYS	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
%systemdrive%	Full Control	Full Control	Full Control (subfolders and files only)	Read & Execute, List Folder Contents, Read (this folder, subfolders, and files) Create Files (subfolders only) Create Folders (this folder and subfolders only)	Modify (subfolders and files only)
%systemdrive%\ autoexec.bat	Full Control	Full Control			Read & Execute (this folder only)
%systemdrive%\ boot.ini	Full Control	Full Control			Read & Execute (this folder only)
%systemdrive%\ config.sys	Full Control	Full Control			Read & Execute (this folder only)
%systemdrive%\ Documents and Settings	Full Control	Full Control	Full Control (subfolders and files only)	Traverse Folder/Execute File, List Folder Contents (this folder only)	Traverse Folder/Execute File, List Folder Contents (this folder only)
%systemdrive%\ Documents and Settings\Administrator	Full Control	Full Control
%systemdrive%\ Documents and Settings\All Users	Full Control	Full Control		Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemdrive%\ Documents and Settings\Default User	Full Control	Full Control		Read and Execute, List Folder Contents, Read	Read and Execute, List Folder Contents, Read
%systemdrive%\ MSDOS.SYS	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
%systemdrive%\ ntbootdd.sys	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
%systemdrive%\ ntdetect.com	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
%systemdrive%\ ntldr	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
%systemdrive%\ Temp	Full Control	Full Control	Full Control (subfolders and files only)	Traverse Folder/Execute File, Create Files/Write Data, Create Folders/Append Data (this folder and subfolders only)	Traverse Folder/Execute File, Create Files/Write Data, Create Folders/Append Data (this folder and subfolders only)
%systemdrive%\ addins	Full Control	Full Control	Full Control (subfolders and files only)	Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read (this folder, subfolders, and files) Modify (this folder and subfolders only)
%systemroot%	Full Control	Full Control	Full Control (subfolders and files only)	Read & Execute, List Folder Contents, Read (this folder, subfolders, and files) Create Files (subfolders only) Create Folders (this folder and subfolders only)	Modify (subfolders and files only)
%systemroot%\ $NtServicePackUninstall$	Full Control	Full Control
%systemroot%\ Application Compatibility Scripts	Full Control	Full Control			Read & Execute, List Folder Contents, Read
%systemroot%\ AppPatch	Full Control	Full Control			Read & Execute, List Folder Contents, Read
%systemroot%\ Cluster	Full Control	Full Control
%systemroot%\ Config	Full Control	Full Control			Read & Execute, List Folder Contents, Read
%systemroot%\ Connection Wizard	Full Control	Full Control			Read & Execute, List Folder Contents, Read
%systemroot%\ Connection Wizard	Full Control	Full Control			Read & Execute, List Folder Contents, Read
%systemroot%\ CSC	Full Control	Full Control
%systemroot%\ debug	Full Control	Full Control	Full Control (subfolders and files only)	Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemroot%\ Debug\UserMode	Full Control	Full Control		Traverse Folder/Execute File, List Folder/Read Data, Create Files/Write Data (this folder only) Create Files/Write Data, Create Folders/Append Data (files only)	Traverse Folder/Execute File, List Folder/Read Data, Create Files/Write Data (this folder only) Create Files/Write Data, Create Folders/Append Data (files only)
%systemroot%\ Driver Cache	Full Control	Full Control		Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemroot%\ Help	Full Control	Full Control
%systemroot%\ inf	Full Control	Full Control		Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemroot%\ installer	Full Control	Full Control			Read & Execute, List Folder Contents, Read
%systemroot%\ java	Full Control	Full Control	Full Control	Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read (this folder, subfolders, and files) Modify (subfolders and files only)
%systemroot%\ media	Full Control	Full Control		Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemroot%\ msagent	Full Control	Full Control		Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemroot%\ Registration	Full Control	Full Control		Read	Read
%systemroot%\ repair	Full Control	Full Control		List contents (this folder only)	Modify
%systemroot%\ security	Full Control	Full Control		Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemroot%\ ServicePackFiles	Full Control	Full Control
%systemroot%\ system32\	Full Control	Full Control	Full Control (subfolders and files only)	Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemroot%\ system32\ appmgmt	Full Control	Full Control		Read & Execute, List Folder Contents, Read
%systemroot%\ system32\ Netmon	Full Control	Full Control
%systemroot%\ system32\GroupPolicy	Full Control	Full Control		Read & Execute, List Folder Contents, Read	Read & Execute, List Folder Contents, Read
%systemroot%\ system32\ias	Full Control	Full Control	Full Control (subfolders and files only)
%systemroot%\ system32\config	Full Control	Full Control	Full Control (subfolders and files only)	Read & Execute (this folder and subfolders only)	Read & Execute (this folder and subfolders only)
%systemroot%\ system32\ NTMSData	Full Control	Full Control
%systemroot%\ system32\spool\printers	Full Control	Full Control	Full Control (subfolders and files only)	Traverse Folder/Execute File, Read Attributes, Read Extended Attributes, Create Folders/Append Data (this folder and subfolders only)	Traverse Folder/Execute File, Read Attributes, Read Extended Attributes, Create Folders/Append Data (this folder and subfolders only)
%systemroot%\ Temp	Full Control	Full Control	Full Control (subfolders and files only)	Traverse Folder/Execute File, Create Files/Write Data, Create Folders/Append Data (this folder and subfolders only)	Traverse Folder/Execute File, Create Files/Write Data, Create Folders/Append Data (this folder and subfolders only)
c:\autoexec.bat	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
c:\boot.ini	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
c:\config.sys	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
c:\ntbootdd.sys	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
c:\ntdetect.com	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder only)
c:\ntldr	Full Control (this folder only)	Full Control (this folder only)			Read & Execute (this folder)

You can apply the built-in security template Rootsec.inf to restore the permissions to the default inheritance hierarchies. Applying this template will not affect explicit permissions or nondefault folders.

Note that the first time that a user logs on to a Windows XP computer causes a profile for her to be created in the %systemroot%\Documents and Settings directory. The operating system applies the permissions Administrators, System, and User accounts Full Control OI, CI, rather than inheriting the permissions from the Documents and Settings folder.

Securing Files and Folder Access by Using Share Permissions

NTFS permissions always apply to files and folders, regardless of whether they are accessed locally or over the network through a file share. When you share a folder, the share and its contents are accessed via the server service running on the machine on which the share is created. Share permissions differ from NTFS permissions in that they apply only when the share is accessed via the network and they do not offer the level of granularity provided by NTFS permissions. Table 7-8 explains the permissions that you can assign to a share.

Table 7-8. Share Permissions
Permissions	Description
Full Control	Full control over all folders and files in the share
Change	Read and Write permissions to files and folders
Read	Read permission for files and folders

By default in Windows 2000 and Windows XP, when a share is created, the share permissions are set to Everyone Full Control. Like NTFS permissions, share permissions are cumulative. Furthermore, deny permissions override allow permissions.

When a user attempts to access a file or folder on a share, cumulative share permissions as well as the cumulative NTFS permissions are calculated. The user accessing the share receives the more restrictive set of these two sets of permissions. For example, if the share permissions are left to the default setting of Everyone Full Control and the user has only Read and Execute rights on the files and folders in the share, the user will have only Read and Execute access.

Although share permissions are not nearly as granular as NTFS permissions, they are still useful if implemented correctly. For example, you can achieve a higher degree of security on a share s contents by removing the default share permissions and granting members of the Everyone group Change permissions. This will prevent the changing of permissions on the files and folders in the share remotely, through the network redirector. This is particularly important because the user who creates a file owns that file and can reassign permissions in a manner that compromises security. When you remove the Everyone Full Control share permission, the owner of a file can modify only permissions via an interactive logon session, either at the server console or through Terminal Services.