Default ACLs The following tables show ACLs for the root of the system drive (usually C:\) and Windows (C:\Windows) directory, in Windows XP, Vista, Server 2003 and 2008. The table data was created using cacls.exe, which has been superseded by icacls in Vista. Because icacls has a slightly different output, to avoid confusion cacls has been used to generate the table data for all operating systems. The output of these commands can be a little confusing if you’ve never used them before (Table 1), so you might like to compare the tables with the GUI in Figure 6 and Figure 7.
The root directory of the system drive (C:\) BUILTIN\Administrators and SYSTEM permissions have been divided into two ACEs. The Everyone and CREATOR OWNER ACEs have gone. BUILTIN\Users’ ACEs are replaced by Authenticated Users, with the exception of the BUILTIN\Users:(OI)(CI)R ACE, which cancels out the effect of removing Everyone.
The main difference is the absence of CREATOR OWNER. In Vista, when a user creates a folder in the root of the system drive, the user is not assigned any specific permission. Authenticated Users are assigned MODIFY permission. CREATOR OWNER remains in Windows Server 2008 as shown in Table 2 (see also Figure 8 and Figure 9.
The Windows directory (C:\Windows) Permissions on the Windows directory have changed a little (Table 3). Power Users are gone and TrustedInstaller is in. ACEs for SYSTEM and BUILTIN\Administrators have been modified slightly, specifying different permissions: MODIFY for the top-level Windows directory and FULL CONTROL for subfolders and files. Hence, if you view these permissions using Vista’s GUI, you’ll see two entries for BUILTIN\Administrators and SYSTEM respectively (Figure 10 and Figure 11).
In Windows XP, Operating System (OS) files in the Windows directory were assigned Full Control for the Administrators group by default. That’s changed, and now a new SID called TrustedInstaller has full control and ownership of OS files (Table 4). This change is designed to prevent an application installer from automatically replacing OS files when run with administrator credentials (see also Figure 12 and Figure 13).
Junction Points have been added to Vista for the purposes of backwards compatibility. The Documents and Settings Junction Point, has an ACE of Deny for the Everyone group applied. This is to stop users from directly accessing or deleting the Junction Point. The Everyone group does however have the Bypass Traverse Checking right assigned to such Junction Points. This allows legacy programs to access files by specifying the full path for the file, but prevents casual users from browsing.
UAC behaviour and ACLs When you browse to a folder that you do not have permission to read, UAC presents you with a dialog: You don’t currently have permission to access this folder – Click Continue to get access to this folder. What the dialog doesn’t make clear is exactly how you'll be granted access. When UAC grants access to a file or folder, unlike other UAC operations Windows Explorer isn’t restarted with an elevated token that grants temporary read access to the folder. Instead, a permanent READ ACE is created on the object, which in turn is inherited by all child objects. You might notice a short delay when you click Continue. This is because the new ACE is being added to the objects in the folder’s hierarchy. So don’t be surprised if after such an operation, a limited user has read access to part of the file system which they previously did not.
When writing to a folder for which you don’t have the necessary permissions, the behaviour is different. Try copying a file to a folder for which you don’t have write permission, and you’ll be presented with a similar UAC dialog: You’ll need to provide administrator permission to copy to this folder. The file will be copied, but only read access will be granted to the copied file.