Windows 的NTFS文件系统为每个文件和文件夹都提供了一个访问控制列表ACL。ACL由一系列访问控制项（ACE）组成。每个ACE包含一个安全标识符（SID）和赋予那个SID的访问权限。访问权限可以是允许访问或拒绝访问，而SID可能代表用户账户、计算机账户或者组。ACE可以由系统管理员、文件所有者或者具有“应用权限的权限”的用户来指派。

用户登录Windows之后，系统会为当前账户创建一个访问令牌，它包含了当前账户的SID、当前账户隶属的组的SID，以及当前账户拥有的特权（用特殊身份的SID代表）。当用户访问系统资源的时候，系统将比较用户的令牌和所访问资源上的ACL，决定用户是否具有访问权限及何种访问权限。

下面让我们在Windows 7下先分别看一看ACL和访问令牌，然后检验一下ACL的功能。

（1）查看访问控制列表ACL。

在NTFS文件系统中的任意文件或文件夹上单击右键，如我们在上一章的实践操作中创建的文件cert.pfx，选择“属性”，再选择“安全”标签，如图3-17所示。该图中的“组和用户名”下显示的是4个对文件cert.pfx具有相应访问权限的用户账户或组账户名称（注意，ACL中实际存储的是这些账户的SID而非名称，SID是一个以S开头的数字串，每个SID都是唯一的）。选择其中的某一项，该窗口的下半部分则显示该SID对文件cert.pfx的访问权限。这些内容就是文件cert.pfx的ACL，并且有4个ACE。

图3-17　访问控制列表

（2）查看当前用户账户的访问令牌。

这里使用进程管理工具ProcessHacker来查看账户的访问令牌。以管理员身份运行该程序，其界面如图3-18所示。“User Name”一栏显示的是运行该进程账户，该图显示有4个账户System、Local Service、Network Service和Owner运行了这些进程。Owner是当前用户账户，其他3个是系统账户。注意，如果以默认的身份运行ProcessHacker，则许多进程的“User Name”一栏将为空。

图3-18　ProcessHacker的主界面

图3-18只显示了一个以当前账户的身份启动的进程dllhost.exe，这个进程不是当前用户直接启动的，而是系统帮助启动的。这里我们手动启动几个普通程序，如记事本、画图等。然后在ProcessHacker的窗口中，找到“User Name”为Owner的进程，如notepad.exe（记事本）进程，单击右键，选择“Properties”，选择Token标签，结果如图3-19所示。该图中显示了账户Owner的SID值，以及账户Owner所隶属的组及特权身份（SID已替换成名称）。选择Owner启动的另一进程mspaint.exe（画图），查看其携带的令牌。你会发现，除了窗口标题栏显示的进程名称和进程标识PID不同外，其他和notepad.exe进程是一样的。但是，如果查看进程dllhost.exe携带的令牌，则内容与notepad.exe和mspaint.exe并不完全相同。

图3-19　账户Owner的令牌

除了查看当前用户账户的令牌，你也可以查看其他账户的令牌，如系统账户System在某个进程上的令牌，如图3-20所示。

（3）验证ACL的效果。

这里要使用前一个实践操作创建的Alice、Bob、Bashar及Trump账户，如果在你的计算机上没有这些账户，你应该先创建这些账户，可以不设置口令。这些账户中Trump是管理员账户，而Alice、Bob、Bashar是标准账户。

图3-20　账户System在进程services.exe（500）上的令牌

在默认的管理员账户下，先查看D：盘根目录下文件夹Share的访问控制列表，如图3-21所示。与图3-17比较一下，你会发现文件cert.pfx的访问ACL与Share的ACL是完全一样的（只是Share文件夹多了一条“浏览文件夹内容”）。这是因为它们都继承了D：盘根目录的ACL。然后，进入Share文件夹，创建一个文本文件readme.txt，内容为“Hello！”。如果你查看readme.txt的ACL，你会发现它继承了Share文件夹的ACL。

图3-21　文件夹Share的访问控制列表

然后更改D：盘根目录下文件夹Share的访问控制列表：

① 添加账户Alice，并设置“完全控制”权限，方法如下：在文件夹Share的安全属性对话框中选择“编辑”→“添加”，在弹出的“选择用户和组”对话框中，选择“高级”→“立即查找”，在“搜索结果”中选择“Alice”，单击“确定”，选择“完全控制”，如图3-22所示。

② 添加账户Bob，并设置拒绝“读取”，方法同前，设置结果如图3-23所示。

③ 添加账户Trump，并设置拒绝“完全控制”，设置结果如图3-24所示。单击“确定”，单击“是”。(www.daowen.com)

图3-22　为账户Alice设置完全控制文件夹Share的访问权限

图3-23　为账户Bob设置拒绝读取文件夹Share的访问权限

图3-24　为账户Trump设置拒绝完全控制文件夹Share的访问权限

在继续后面的操作之前，先说明一下，在Windows 7下，管理员账户默认隶属于组Administrators和Users，标准用户账户默认隶属于Users组。你可以通过如下操作查看账户Trump和Alice所隶属的组：“控制面板”→“系统和安全”→“管理工具”→“计算机管理”→“本地用户和组”→“用户”，在Trump或Alice上单击右键，选择“属性”→“隶属于”，如图3-25和图3-26所示。

图3-25　管理员Trump所隶属的组

图3-26　标准账户Alice所隶属的组

切换用户，以Bashar账户登录系统，然后访问D：\Share下的Readme.txt文件，该文件能够正常打开。这很好解释，因为Bashar隶属于Users组，而User组对Readme.txt具有“读取和执行”的权限（继承自Share的ACL），如图3-27所示。

图3-27　User组对Readme.txt具有读取和执行的权限

现在尝试在Share下创建文件，也成功了。在文件夹Share的ACL中，Users组仅具有“读取和执行”的权限，并没有“写入”的权限。那为什么Bashar账户可以创建文件呢？原因是Share的ACL中有一个特殊的组账户“Authenticated Users”，它对文件夹Share具有可读、可写的权限，如图3-21所示。“Authenticated Users”指Windows系统中所有使用用户名、密码登录并通过身份验证的账户（但不包括来宾账户Guest，即使来宾账户有密码）。这就是Bashar账户可以在Share下创建文件（当然也可以创建文件夹）的原因。这也是NTFS的权限累加原则的实际应用。

切换用户，以Bob账户登录系统，然后进入D：\Share文件夹，结果被拒绝，如图3-28所示。原因如下：尽管Bob和Bashar都是标准用户，默认情况下都可以进入Share文件夹并打开和创建文件，但是因为在前面我们在Share的ACL上为Bob设置了拒绝“读取”权限，而NTFS的拒绝权限的优先级高于允许权限。事实上，不仅标准用户如此，管理员用户也是如此。

图3-28　Bob访问文件夹Share被拒绝

切换用户，以管理员账户Trump登录系统，然后进入D：\Share文件夹，结果也被拒绝。原因同上。

切换用户，以最初的管理员账户登录系统，再次更改D：盘根目录下文件夹Share的访问控制列表，删除其中的“Authenticated Users”账户。方法如下：打开“Share的安全属性对话框”→“高级”→“更改权限”→ 取消“包括可从该对象的父项继承的权限”→“添加”。这会取消对父项的ACL的继承并复制一份与父项相同的ACL，这样才可以删除其中的ACE，而继承的ACE无法被删除，如图3-29所示。接下来选择其中的“Authenticated Users”账户，单击“删除”按钮，单击“确定”3次。

图3-29　取消Share对父项ACL的继承并复制一份

再次切换到Bashar账户，然后访问D：\Share下的Readme.txt文件，可以打开。尝试在Share下创建文件或文件夹，无法创建。刚才可以创建，现在不能，为什么？你能解释吗？

现在切换到Alice账户，，然后访问D：\Share下的Readme.txt文件，可以打开。尝试在Share下创建文件或文件夹，创建成功。Alice和Bashar及Bob都是标准用户，为什么Bashar不能在Share下创建而Alice可以呢？因为我们曾经在Share的ACL上专门为Alice添加了一个“完全控制”的ACE，如图3-22所示。