CN102341809A - 分布式文件系统访问 - Google Patents

Abstract

一种用于在分布式文件系统中提供访问的系统和方法。本公开描述了用于在分布式文件系统(DFS)中提供对文件系统对象的访问的系统和方法。在一个实现中，对DFS中的文件系统对象的访问仅限于验证通过的用户和客户机设备。为此，DFS的客户机设备可被划分为可信客户机和不可信客户机，并且进一步地拒绝不可信客户机的访问。可利用可信计算的概念获取可信客户机。向系统添加的新客户机可作为不可信客户机进行添加。进一步地，可以通过将文件访问权限扩展为包括可控制不可信客户机访问的其他位来限制访问。在某些情况下，可允许对象所有者从不可信客户机访问对象。

Description

分布式文件系统访问

背景技术

文件系统一般为用于存储、分层组织、操纵、导航、访问和检索数据的数据库。分布式文件系统(DFS)作为一种文件系统版本，近几十年来日趋流行。DFS，正如其名称所暗示的，是一种网络文件系统，其中单个文件系统可以跨多个物理计算设备分布，并且所述计算设备可以直接访问整个文件系统的部分。DFS一般包括透明复制和容错功能。也就是说，当文件系统中有限数量的节点脱机时，系统可以继续工作而不丢失任何数据。因此，对于组织、公司等中的局域网(LAN)来说，DFS已成为一个非常流行的选择。

在一般的计算机操作系统中，存储文件时带有关联的访问权限，且只有拥有充足访问权限的用户才被允许访问文件。传统上，在三个级别(即，所有者、组以及其他用户)上授予文件访问权限。每个级别都有其自己的权限，可以根据用户所在级别的访问权限授予用户访问权限。此外，在多数文件系统中，每个文件具有关联的所有者标识(ID)(即，创建文件系统对象的用户的ID)和组ID(即，所有者可以是一个或多个组的一部分)。在多个用户可以访问同一机器上的文件的场合，现有的文件访问权限降低了本地文件系统的安全风险(在很大程度上)，但是在分布式文件系统中，所述文件访问权限会带来漏洞。

在DFS中，位于不同计算设备上的多个用户可以访问单个文件系统对象。因此，在DFS中，文件访问权限带来了一些问题。这些问题的发生是因为在DFS中，不需要用户ID在系统中的所有计算设备上是唯一的。例如，两个用户(例如，用户A和用户B)在不同的客户机设备上可以具有同一用户ID(例如，ID 1000)。这样，当用户A尝试访问用户B创建的文件时，将允许用户A访问该文件(根据该文件的所有者访问权限)，即使用户A并未创建该文件。系统允许此操作是因为文件访问权限仅识别用户ID，因为这两个用户具有相同的用户ID，用户A和用户B均被认为是该文件的所有者。因此，可以轻松地伪装成真实用户，从而造成严重的安全威胁。

已经提出了多种方法来克服DFS中的某些安全问题。一些方法将用户ID和组ID集中于一中央储存库中，这样确保没有两个用户具有相同的用户ID。每当用户请求访问文件对象时，都会使用所述储存库验证用户凭据。但是，仍有可能绕过中央储存库并在LAN中安装客户端设备。进一步地，用户仍可以在新安装的客户端设备上伪造用户ID。此外，由于所有用户ID都存储在中央服务器内，因此，如果中央储存库崩溃，整个系统也会崩溃。

其他方法包括使用公共和私有加密密钥。这些方法还结合使用加密密钥使用中央储存库。一旦用户通过中央储存库被验证通过，则添加需要加密密钥的附加安全级别。如果用户没有该密钥，则拒绝其访问。这些系统可能非常复杂并需要对管理员进行全面的培训。进一步地，就像本领域中已知的其他方法一样，此方法也包含单个故障点(single point of failure)。

发明内容

本发明的实施例涉及用于在分布式文件系统中提供对文件系统对象的访问的方法和系统。

根据第一方面，提供了一种用于在分布式文件系统中提供访问的方法，所述方法包括：检索请求用户的用户标识(ID)和客户机ID；判定所述客户机ID是否对应于可信客户机或不可信客户机中的至少一个；获取文件系统对象的扩展访问权限，其中所述扩展访问权限指示所述文件系统对象是否是在可信客户机上创建的以及不可信客户机是否可以访问所述文件系统对象；以及根据所述用户ID、客户机ID和文件系统对象的扩展访问权限允许访问所述文件系统对象。

在第一实施例中，描述了一种用于在分布式文件系统(DFS)中提供访问的方法。所述方法包括检索请求用户的用户标识(ID)和客户机ID并判定所述客户机ID对应于可信客户机还是不可信客户机的步骤。所述方法进一步包括获取文件系统对象的扩展访问权限并允许根据所述用户ID、客户机ID和文件系统对象的扩展访问权限访问所述文件系统对象。所述对象的扩展访问权限可包括指示所述文件系统对象是否是在可信客户机上创建的T位，以及指示是否允许所述请求用户从不可信客户机访问所述文件系统对象的L位。

应该理解，尽管此处的示例指示可信客户机根据可信计算组(TrustedComputing Group)定义的原理运行，但是并不是必须如此。特定的客户机可能因为按照特定的方式运行而被识别为“可信的”。它们可能，例如，安装了特定的软件或使用了特定类型的硬件。

根据第二方面，提供了一种用于在分布式文件系统中提供访问的系统，所述系统包括：用于存储文件系统对象的存储器；用于执行以下操作的处理设备：检索请求用户的用户ID和客户机ID；判定所述客户机ID对应于可信客户机还是不可信客户机；获取文件系统对象的扩展访问权限，其中所述扩展访问权限指示所述文件系统对象是否是在可信客户机上创建的以及不可信客户机是否可以访问所述文件系统对象；以及允许根据所述用户ID、客户机ID和文件系统对象的扩展访问权限访问所述文件系统对象。

在第二实施例中，描述了一种用于在DFS中提供访问的系统。所述系统包括存储器和操作地与所述存储器相连以检索请求用户的用户ID和客户机ID并判定所述客户机ID对应于可信客户机还是不可信客户机的处理设备。此外，所述系统获取文件系统对象的扩展访问权限，其中所述扩展访问权限包括指示所述文件系统对象是否是在可信客户机上创建的T位，以及指示是否允许所述请求用户从不可信客户机访问所述文件系统对象的L位。进一步地，所述系统允许根据所述用户ID、客户机ID和文件系统对象的扩展访问权限访问所述文件系统对象。

还提供了一种计算机程序，其提供了当所述程序运行在计算机上时适于执行第一方面的方法的计算机程序装置。

附图说明

现在参考下面的附图，仅通过举例，描述本发明的实施例：

图1是示出根据一个实施例可在其中实施本发明的示例性分布式文件系统(DFS)的方块图。

图2示出根据本发明的某些实施例的虚拟文件系统的方块图。

图3示出根据本发明的某些实施例的示例性扩展访问权限。

图4是示出其中可允许或拒绝用户访问文件系统对象的示例性场景的图。

图5是根据本发明的实施例用于在分布式文件系统中提供对文件系统对象的访问的方法的流程图。

图6是根据本发明的实施例用于判定对分布式文件系统中的文件系统对象的访问的方法的流程图。

具体实施方式

下面的详细说明是参考附图做出的。优选实施例的描述是为了说明本发明，并非对其范围做出限制，所述范围由权利要求定义。本领域的技术人员将理解下面描述的各种等效的变形。

本发明的实施例描述了一种用于在分布式文件系统(DFS)中提供访问的方法。所述方法允许真实用户访问文件系统对象。进一步地，所述方法允许用户从真实的客户机设备访问文件系统对象。本发明的另一实施例使用用户标识(ID)和客户机ID的组合识别唯一的用户。进一步地，在所公开的解决方案中使用了可信计算的概念。在一个实施例中，可以扩展文件系统访问权限以增强分布式文件系统中对象的安全性。

示例性操作环境

图1是示出根据优选实施例可在其中实施本发明的示例性分布式文件系统(DFS)100的方块图。DFS 100包括将一个或多个文件系统服务器计算设备104-A、104-B(文件系统服务器104)、一个或多个客户机计算设备106-A、106B、106-C和106-D(客户机106)以及中央储存库108进行互连的网络102。进一步地，一个或多个用户110-A、110-B、110-C和110-D(用户110)可以通过网络102，从客户机106访问文件系统服务器104中存储的对象。文件系统对象可包括文件、目录、文件夹、文档和一般存储在数字媒体上的其他类似对象。

在DFS 100中，各种文件系统可以跨文件系统服务器104分布，这些服务器可能位于不同的地理位置，但是逻辑上被映射在根DFS文件夹下。因此，用户110不需要了解文件系统服务器104的确切位置。进一步地，DFS 100可包括透明复制和容错功能，以便当有限数量的文件系统服务器104脱机时，DFS 100继续工作且不丢失任何数据。

网络102可以是本领域中已知的任何有线或无线网络。例如，所述网络可以是局域网(LAN)、城域网(MAN)、因特网等。在一个实施例中，网络102是连接在多个国家分布的多个办公室PC、各种服务器以及其他基于计算的设备的专用网，例如公司网络。另一方面，网络102包括家庭网络，其中属于单个家庭的有限个PC通过WLAN连接。在其他实施例中，网络102可连接小型企业中的有限个客户机。将理解，网络类型不限制本发明的范围，可以使用任何已知的网络配置实现DFS 100。

进一步地，DFS 100可以在本领域中任何已知的操作系统上运行，所述操作系统例如为

AIX操作系统、Solaris Filesystem、

文件系统、

操作系统、MAC操作系统等。本发明的实施例参考

操作系统进行描述，尽管可以替代地使用本领域中任何已知的操作系统。(IBM和AIX是国际商业机器公司在美国和/或其他国家的商标；Microsoft和Windows是微软公司在美国和/或其他国家的商标；Linux是Linus Torvalds在美国和/或其他国家的注册商标；UNIX是TheOpen Group在美国和/或其他国家的注册商标；其他产品和服务名称可能是IBM或其他公司的商标)。

此外，文件系统服务器104和客户机106可以配备有存储器、处理设备、输入/输出端口、网络端口等。在图1中，文件系统服务器104-A被示出为带有存储器112和处理设备114。处理设备114可包括微处理器、微计算机、微控制器、数字信号处理器、中央处理单元、状态机、逻辑电路和/或根据操作指令操纵信号的任何设备。除其他功能之外，处理设备114被配置为获取和执行存储器112中存储的计算机可读指令。存储器112可包括本领域中已知的任何计算机可读介质，其中包括，例如，易失性存储器(例如，RAM)和/或非易失性存储器(例如，闪存等)。存储器112和处理设备114可具有任何适当的物理实现并且它们可以根据特定的设备实现，在操作上相连接。这些组件可以被改造、安排、配置和设计以执行根据此处教导的(例如，如参考图2-6示例性说明的)方法。对于本领域的技术人员显而易见的是，客户机106和文件系统服务器104中的每一个可以配备有存储器和处理设备。

进一步地，本发明的实施例限制未授权的客户机(即，DFS 100未识别的客户机)上的用户的访问，并允许未授权的客户机上的授权用户的访问。为此，所有客户机106根据可信计算的原理被分为两组，即可信客户机和不可信客户机。

可信计算(TC)是由可信计算组开发和推广的技术。借助可信计算，客户机106始终地以硬件和软件所实施的特定方式运行。实施可信行为是通过将唯一ID和唯一主密钥加载到硬件以及拒绝甚至客户机所有者了解和控制主密钥来实现的。可信计算不仅为所有者保护硬件，而且也通过防备所有者来保护硬件，从而禁止用户伪装授权用户。在本领域中已知许多技术用于实现可信计算，例如Network Filesystem(NFS)、NetworkInformation Service(NIS)、轻型目录访问协议(LDAP)等。任何已知的技术都可用于实现TC。

在一个实现中，可使用NIS。在NIS中，客户机ID存储在中央储存库例如中央储存库108中。每个客户机都有它可支持的用户ID的列表。由于客户机ID是集中存储的，因此NIS确保没有两个客户机具有相同的用户ID，从而确保唯一的用户ID。在网络102中安装的尝试访问文件系统服务器104的新客户机被视为不可信客户机，因为NIS不能确定该客户机是否具有唯一的用户ID。一旦NIS配置该客户机并且该客户机上的用户ID与可信客户机上的用户ID相协调，该客户机便可升级到可信客户机组。

图1示出可信客户机116和不可信客户机118。可信客户机116包括客户机106-A、106-B和106-C，不可信客户机118包括客户机106-D、106-E。在一个实现中，可信客户机116和不可信客户机118可被包括在文件系统服务器104的存储器112中存储的客户机列表中。在另一实现中，所述客户机列表可被存储在中央储存库108中。进一步地，网络102中的新客户机可被直接添加为不可信客户机118。一旦NIS对用户ID验证通过，该客户机便可升级为可信客户机116。

当用户请求DFS 100上的文件系统对象时，NIS使用客户机列表验证用户的客户机ID。如果用户的客户机ID不在所述客户机列表中，则NIS不允许用户110进行访问。如果客户机ID存在于所述客户机列表中，则文件系统服务器104确认用户110是否提供了正确的用户ID。基于所述确认，使用文件系统对象的访问权限检查用户ID。

通过这种方式，本发明的实施例确保用户110可具有唯一的标识，并且不是唯一标识机制一部分的客户机可为不可信客户机118。通过区分可信客户机和不可信客户机，使得文件系统服务器104允许可信客户机116上的真实用户访问文件系统服务器104，同时拒绝不可信客户机118上的伪用户进行访问。

另外，可以使用多种技术唯一地识别用户110。在一个实现中，可使用用户ID和客户机ID的组合识别用户，其中所述客户机ID对应于用户通常在上面的执行操作的客户机。所述用户ID和客户机ID的组合可以采取任何形式，例如数字值、字母数字值、用户名、MAC地址、用户个人信息等。在另一实现中，诸如数字值、字母数字值等之类的任何唯一ID可被视为用户ID。

因此，根据本发明的实施例，对文件系统对象的访问基于用户ID、客户机ID和文件系统对的访问权限。因为用户不仅通过他们的用户ID定义，而且还通过他们各自的位置(用户位于可信客户机上还是不可信客户机上)定义，所以必须修改对象的传统访问权限以便根据用户位置提供不同的访问权限。为此，本发明的实施例将一些新的位添加到当前文件系统的访问权限上并使现有的访问权限位过载。将结合图3提供扩展访问权限的说明。

传统访问权限

下面几节描述传统文件访问机制，因为需要了解一些有关传统访问权限的知识来理解所公开的解决方案中的扩展访问权限。将参考UNIX操作系统说明传统访问权限。但是应该理解，可以参考本领域中已知的其他任何操作系统说明传统访问权限。每个操作系统都有自己的语法、命令、文件名等，但是传统访问权限的基本概念在典型的操作系统中保持不变。

在UNIX中，可使用用户ID和至少一个组ID识别用户。此外，一个组中的用户可以被归类到一个组ID之下。例如，一个组织中可能包含各种小组，例如财务组、人力资源组和IT组等。财务组的成员可被分组到财务组ID之下，人力资源组可被分组到人力资源组ID之下，以此类推。进一步地，小组的管理者可被组织到行政组ID之下。管理员或根用户(rootuser)可管理组ID。一般而言，所有文件系统对象都包括创建该文件系统对象的所有者的用户ID以及所有者所属组的组ID。

传统访问权限可以是用于诸如对象所有者、组成员或其他任何用户之类的不同用户级别的诸如读权限、写权限和执行权限之类的权限。UNIX一般指定9位访问权限，这些权限被描述为三个八进制数字。每个八进制数字分别表示所有者权限、组成员权限或其他任何用户的权限。第一个八进制数字表示用于对象所有者的访问权限，接下来的八进制数字表示允许所有者所属组的成员的访问权限，最后一个八进制数字表示用于其他任何用户的访问权限。进一步地，所述八进制数字的每个二进制位表示诸如读权限、写权限和执行权限之类的单独权限。第一位指示读权限，第二位指示写权限，第三位指示执行权限。如果位值为1，则激活权限，否则阻止权限。例如，八进制数字7的二进制值为111，这指示用户拥有对文件系统对象的读权限、写权限和执行权限。

诸如对象所有者或管理员之类的授权用户一般指定访问权限。在某些情况下，可针对进程或环境预设访问权限，从而在所述进程或环境中创建的所有对象自动拥有指定给该进程或环境的访问权限。授权用户可以在对象创建之后随时修改其访问权限。

在UNIX系统中，传统访问权限存储在称为inode(索引节点)的元数据文件中，该文件存储有关常规文件、目录或其他文件系统对象的基本信息。每个文件系统对象可具有一inode和一inode编号(通常称为“i编号”或“inode”)，所述编号可以在文件系统或inode所在的地方识别inode。

一般而言，inode存储有关文件系统对象的信息，例如所有者的用户ID、组ID、访问权限(读权限、写权限和执行权限)以及对象类型。进一步地，inode编号索引到在设备的已知位置上的inode表；通过所述inode编号，内核可以访问inode的内容和文件系统对象的内容。传统上，内核搜索目录以查找特定的文件名，然后将所述文件名转换为正确的对应inode编号。

DFS 100具有多个文件系统，且在某些实施例中，所述文件系统可以具有不同的类型，例如，

文件系统、

文件系统、

文件系统、Mac OS文件系统、

文件系统等。每个文件系统服务器104都可具有自己存储有关文件系统对象的元数据的方式。为了用户无缝地访问来自不同文件系统的对象，在DFS 100中的文件系统服务器104之上可提供虚拟文件系统(VFS)抽象层。

示例性虚拟文件系统

图2示出VFS 202及其与各种文件系统服务器104的关系。VFS 202可允许客户机106以统一的方式访问不同类型的文件系统服务器104。而且，VFS 202，例如，可用于透明地访问本地服务器和网络服务器，而客户机106注意不到差别。在一个实现中，VFS 202桥接各种文件系统中的差别，以便客户机106可以访问文件系统上的对象，而不需要了解文件系统的类型。

为了检索不同文件系统的inode，VFS 202使用称为vnode 204的数据结构。所有文件操纵可以通过包括公共数据和私有数据的vnode 204完成。每个vnode 204中的公共数据字段包括仅由VFS 202层操纵的数据或者在文件系统对象的生命周期内不改变的文件系统对象数据，例如文件类型。vnode 204中的私有数据字段指向依赖于文件系统的数据，例如文件系统的inode表。Vnode 204被示出为带有文件系统服务器104的inode表项。

文件系统的vnode 204可指向特定文件系统服务器104的文件系统对象的inode编号。因此，在DFS 100中，可通过文件系统对象的vnode和/或inode访问对象的访问权限。进一步地，inode中的访问权限字段典型地为16位字段。目前，这16位中有9位用于定义文件系统对象的传统访问权限，而3位用于特殊目的的安全性，从而使得16位访问权限字段中剩下4位未用。

示例性扩展访问权限

图3示出根据本发明的实施例的示例性扩展访问权限300。示例性扩展访问权限300包括11位，这与上述的传统9位访问权限相对。本发明的实施例使用访问权限字段中4个未用位中的2个。扩展访问权限300的前9位(可表示为3个八进制数字)用于指示所有者模式位302、可信客户机上的组模式位304以及其他(其他每个人)模式位306。而且，本发明的实施例修改了模式位的定义。一般而言，第二个八进制数字表示组成员的访问权限，但是根据本发明，第二个八进制数字指示从可信客户机116访问对象的组成员的访问权限。进一步地，第三个八进制数字306指示其他用户的访问权限，而非象先前那样指示其他一些用户的访问权限。在某些实现中，可针对不可信客户机118上的所有者、不可信客户机118上的组成员或其他用户检查其他模式位306。

第10和第11位是本发明的实施例引入的T位308和L位310。T位308指示文件系统对象是在可信客户机116还是在不可信客户机118上创建的。T位308上的已启用状态(例如，位值1)指示文件系统对象是在可信客户机116上创建的，而T位308上的已禁用状态(例如，位值0)指示文件系统对象是在不可信客户机118上创建的。在一个实现中，一旦创建对象之后，处理设备可自动设置T位308。进一步地，当允许所有者访问对象并且所有者从可信客户机116修改对象时，如果T位308先前被禁用，则会被自动启用。

L位310指示是否允许对象所有者访问对象，其中所述所有者是不可信客户机118上的用户。为此，已启用的L位310指示允许所有者从不可信客户机118访问，而已禁用的L位310指示不允许所有者从不可信客户机118访问。在文件系统对象的所有者在可信客户机116上创建文件系统对象，并希望从诸如不可信客户机118之类的另一客户机访问文件系统对象的特殊情况下应用这个位。在这些情况下，所有者可启用L位310，并在对象的inode中添加所述不可信客户机118的客户机ID。根据所有者的要求，可以将任意数量的不可信客户机118添加到inode中。进一步地，所有者可以随时修改不可信客户机118的列表。

在一个实现中，所有者模式位302可根据T位308过载，这意味着访问可针对取决于T位和L位的值以及所有者的位置的不同情况，基于所有者模式位302。例如，如果T位308已启用(即，文件系统对象是在可信客户机116上创建的)并且所有者尝试从可信客户机116访问对象，则访问将基于所有者模式位302。另一方面，如果所有者尝试从不可信客户机118访问对象，则将基于其他模式位306允许所有者进行访问。在L位310已启用并且所有者尝试从一不可信客户机118访问对象(该不可信客户机ID位于对象的inode中)的情况下，将基于所有者模式位302判定访问。此外，如果文件系统对象是在不可信客户机118上创建的(即，T位308已禁用)，则在两种情况下(即，从可信客户机116或不可信客户机118访问)所有者对对象的访问可基于所有者模式位302。

如果对象是在不可信客户机118上创建的(即，T位已禁用)，则访问不仅限于可信客户机116，而且根据其访问模式位，不可信客户机118上的用户也可以访问对象。进一步地，在这种情况下，可信客户机上的组模式位304可被读取为组模式位，并且即使不可信客户机118上的组成员也可以根据这些模式位进行评估。

由于对用户110的访问授权不仅取决于用户ID，而且还取决于客户机ID，因此访问权限可能针对用户110动态地变化。因此，根据客户机ID、用户ID以及扩展访问权限300的T位308和L位310，对象的有效访问权限可以改变。例如，在客户机106-A上工作的用户110-A拥有访问权限为755的文件“confidential.txt”。当用户110-A尝试从诸如客户机106-D之类的不可信客户机118访问该文件时，对象的访问权限可能动态地更改为444。

现在参考图4，该图示出其中可允许或拒绝用户访问文件系统对象的一些示例性场景。图4示出包括可信客户机116和不可信客户机118的系统400。进一步地，每个可信客户机116和不可信客户机118连接到诸如文件系统服务器104-A之类的示例性文件系统服务器。为了进一步示出不同的场景，使用一示例性文件系统对象。例如，在文件系统服务器104-A中存在文件系统对象“confidential.txt”。所述对象的扩展访问权限300可以是下面示例1中所示的权限(结合图3描述)。

1

1

1

1

0

1

0

0

0

1

1

示例1：文件系统对象confidential.txt的扩展访问权限300

示例1的扩展访问权限300指示可信客户机上的所有者拥有完全权限(111)，可信客户机上上组中的用户拥有读权限和执行权限(101)，其他用户没有任何权限(000)。进一步地，扩展访问权限300指示文件是在可信客户机上创建的(T位308已启用)并且所有者可以从不可信客户机118访问文件(L位310已启用)。请求访问文件系统对象confidential.txt的用户可以是该对象的所有者、所有者组中的成员或其他任何用户。当用户尝试从可信客户机116访问该对象时，访问将基于用户类型。例如，当用户为所有者402时，访问将基于所有者模式位302并且所有者402将被允许对该文件的完全访问。当用户在组404中时，将评估可信客户机上的组模式位304并且允许用户读取和执行该文件。当用户为其他用户406时，访问将基于其他模式位306并且将不允许用户访问该文件。

现在在另一场景下，当用户尝试从不可信客户机118访问文件“confidential.txt”时，可能出现多种结果。当用户为所有者402时，可能出现两种情况。在第一种情况下，不可信客户机ID存储在对象的inode中，这种情况下，访问将基于所有者模式位302并且将允许所有者402访问。在第二种情况下，不可信客户机118的ID未存储在对象的inode中，这种情况下，访问将基于其他模式位306并且将不允许所有者402访问该文件。根据本示例，L位310已启用，但是当禁用L位310时，访问将基于其他模式位306并且将不允许所有者402访问。

当用户在组404中时，访问将基于其他用户的权限306并且将不允许用户访问该文件。最后，当用户为其他用户406时，访问将基于其他模式位306并且将不允许用户访问，因为其他模式位306为000。

进一步地，在另一示例中，文件系统对象“salary.txt”可具有下面示例2中所示的扩展访问权限300：

1

1

1

1

0

1

0

0

0

0

0

示例2：文件系统对象salary.txt的扩展访问权限300

图2中所示的扩展访问权限300将指示所有者402在不可信客户机118上创建了该文件(因为T位308已禁用(0))。在这种情况下，所有用户将被视为位于可信客户机116上，即使它们位于不可信客户机118上，并且访问将基于前9位的访问权限。然而，如果所有者402从可信客户机116盖写/替换文件，则T位308自动设置为1(已启用)，并且该文件被视为是在可信客户机116上创建的。

示例性方法

图5示出参考图1至4用于在DFS 100中提供访问的示例性方法500。方法500包括授权访问DFS 100中的被请求文件系统对象的步骤。进一步地，方法500包括检索用户ID和客户机ID，判定客户机是否为可信客户机，查找对象的扩展访问权限300，判定用户类型以及根据扩展访问权限300和用户位置提供访问的步骤。

在步骤502，方法500检索请求用户的用户ID和客户机ID。请求用户可以是请求访问一个文件系统服务器104上的文件系统对象的用户110。在一个实施例中，文件系统服务器104可检索客户机106的客户机ID并将所述客户机ID与中央储存库108或存储器112中的客户机106的列表进行比较。在另一实施例中，文件系统服务器104可使用NIS检索客户机列表和客户机ID。如果客户机ID位于客户机ID的列表中，则NIS或文件系统服务器104接着检查用户的标识。如果用户ID与客户机ID一起被提供，则用户可被验证通过；否则，用户不会被验证通过。在一个实现中，用户ID可以是通过用户ID和客户机ID的组合获取的唯一值。在另一实现中，用户ID可以是任何唯一值。

在步骤504，方法500判定客户机ID对应于可信客户机还是不可信客户机。在一个实施例中，文件系统服务器104可将客户机ID与中央储存库108或存储器112中存储的可信客户机列表进行比较。如果客户机ID出现于可信客户机中，则该客户机为可信客户机；否则，该客户机为不可信客户机。可信计算可维护可信客户机116和不可信客户机118的列表。例如，可使用NIS判定客户机ID对应于可信客户机还是不可信客户机。

在判定客户机是可信客户机还是不可信客户机后，方法500可在步骤506查找文件系统对象的扩展访问权限。在一个实现中，文件系统服务器104的处理设备114可从文件系统对象的vnode 204获取扩展访问权限。在另一实现中，可从对象的inode获取扩展访问权限300。

一旦获取了扩展访问权限300，处理设备114便可在步骤508判定用户类型。在一个实现中，处理设备114可通过包括所有者、可信客户机上的组成员、其他用户、不可信客户机上的所有者或不可信客户机上的组成员的列表判定用户类型。文件系统服务器104可根据用户ID、客户机ID和对象的所有信息作出判定。例如，如果用户ID与对象的inode中的所有者ID匹配，并且客户机ID对应于可信客户机116，则文件系统服务器可以判定用户为可信客户机上的所有者。在另一示例中，如果用户ID与文件系统对象的所有者ID或组ID不匹配，则文件系统服务器104可以判定请求用户为其他用户。

在步骤510，文件系统服务器104可根据用户ID、客户机ID和扩展访问权限允许或拒绝请求用户的访问。在一个实现中，文件系统服务器检查文件系统对象是否是在可信客户机116上创建的以及是否允许用户从不可信客户机118访问文件系统对象。在一个实现中，文件系统服务器104上的处理设备114可检查扩展访问权限的T位308和L位310以判定对象是否是在可信客户机116上创建的以及不可信客户机118上的用户是否可以访问对象。根据所述判定，可获取对象的有效访问权限。处理设备114可根据用户的类型和扩展访问权限300在每次请求对象时评估该对象的有效访问权限(如结合图3所述)。例如，如果用户的类型为可信客户机上的组，则文件系统服务器104可根据可信客户机上的组模式位304提供对象的访问。所述访问是根据一组访问规则提供的，这组访问规则将在下面参考图6详细地说明。

如果根据步骤510的输出，允许请求用户访问文件系统对象，则检索文件系统对象并将其呈现在客户机106上。在一个实现中，可检查文件系统对象的inode编号以判定该对象在文件系统服务器104中的位置。在另一实现中，可检查文件系统对象的vnode 204以判定该对象在DFS 100中的位置。进一步地，将根据与请求用户相关的访问模式位的定义，允许请求用户进行访问。例如，如果用户110只拥有读权限，则用户110不能写/修改或执行对象。

图6是示出判定是否应该授权用户访问的示例性方法600的流程图。方法600包括将用户ID和客户机ID与访问权限进行比较以判定可访问性。

在步骤602，方法600判定客户机是否为可信客户机116。在一个实现中，NIS可检查客户机ID是否与可信客户机ID匹配。可以从中央储存库108或文件系统服务器104获取可信客户机116的列表。在一个实现中，处理设备114还可检查请求用户110的用户ID是否位于一般存储在客户机的存储器内的用户ID列表中。在某些情况下，用户ID还可与客户机ID的列表一起存储在中央储存库108或存储器112中。

如果客户机为可信客户机116(步骤602下面的“是”路径)，则服务器的处理设备114检查用户110是否为根用户(步骤604)，否则在步骤606，处理设备114接着检查用户ID是否对应于所有者ID。

在步骤604，所述方法判定用户是否为根用户。根用户可以是管理员或安全顾问。根用户一般拥有DFS 100中的所有访问权限。如果用户110为根用户，则方法600移至步骤618并且授权用户110访问文件系统对象，而不考虑对象的扩展访问权限300。处理设备114可根据用户ID判定用户110是否为根用户。

如果用户110不是根用户，则在步骤608，处理设备114可检查用户110是否为所有者402。在一个实现中，可使用对象的所有者ID验证用户ID。在一个实现中，可从对象的inode/nvode 204获取所有者ID。如果ID匹配，则可以判定用户110为对象的所有者402。如果用户为所有者402(步骤608下面的“是”路径)，则在步骤612，处理设备114可参考所有者模式位302。

如果ID不匹配(步骤608下面的“否”路径)，则处理设备114检查用户110是否属于组404(在步骤610)。在一个实现中，处理设备可检查文件系统对象的对象vnode 204/inode中的对象的组ID。可将用户ID与对象的组ID进行比较。如果用户属于文件系统对象的vnode中提及的组404，则可参考可信客户机上的组模式位304(步骤616)。如果用户110根据可信客户机上的组模式位304拥有充分的权限，则允许用户110访问对象；否则，拒绝用户110访问。

如果用户110不属于组404，则在步骤614参考其他模式位306。如果用户110根据其他模式位306拥有访问权限，则授权用户110访问对象，否则拒绝其访问。

进一步地，在步骤602，如果客户机为不可信客户机118，则方法600继续到步骤606。在步骤606，判定用户110是否为对象的所有者402。如果用户为所有者402(方块606下面的“是”路径)，则所述方法移至步骤620，否则在步骤614(方块606下面的“否”路径)处理设备114可参照其他模式位306。

在步骤620，处理设备114检查L位310是否已启用。如果L位310已启用(方块620下面的“是”路径)，则方法600移至步骤622，否则方法600移至步骤614(方块606下面的“否”路径)，并且在可授权用户110访问之前先检查其他模式位306。

在步骤622，处理设备114检查不可信客户机118是否包括在对象的vnode 204中。如果不可信客户机118在对象的vnode 204中提及，则在步骤612参考所有者模式位302，否则访问基于其他模式位306。

进一步地，在方法600中，如果T位已禁用(例如，0)，则访问可基于扩展访问权限的前9位并且扩展访问权限可作为传统访问权限被读取。

上面给出的说明仅描述了特定实施例，并非旨在对本发明进行限制，本发明的范围仅由下面列出的权利要求决定。正如在此使用的那样，单数形式的“一”、“一个”和“所述”旨在同时包括复数形式，除非上下文明确指出不是这样。将进一步理解的是，当在本说明书中使用时，术语“包括”和/或“包含”指定存在所述特征、整数、步骤、操作、元件和/或组件，但并不排除存在或增加一个或多个其他特征、整数、步骤、操作、元件、组件和/或由此构成的组。

下面权利要求中的所有装置或步骤加功能要素的对应结构、材料、操作和等同物旨在包括用于与如具体声明的那样的其他所声明的要素结合执行所述功能的任何结构、材料或操作。出于说明和描述目的给出了对本发明的描述，但是所述描述并非旨在是穷举的或是将本发明限于所公开的形式。在不偏离本发明的范围和精神的情况下，许多修改和变化对于本领域的技术人员来说都将是显而易见的。实施例的选择和描述是为了最佳地解释本发明的原理和实际应用，并且使得本领域的其他技术人员能够理解适合于所构想的特定使用的本发明的具有各种修改的各种实施例。

Claims (32)

1.一种用于在分布式文件系统中提供访问的方法，所述方法包括：

检索请求用户的用户标识(ID)和客户机ID；

判定所述客户机ID是否对应于可信客户机或不可信客户机中的至少一个；

获取文件系统对象的扩展访问权限，其中所述扩展访问权限指示所述文件系统对象是否是在一可信客户机上创建的以及一不可信客户机是否可以访问所述文件系统对象；以及

根据所述用户ID、客户机ID和文件系统对象的扩展访问权限允许访问所述文件系统对象。

2.如权利要求1中所述的方法，其中第一位(T)指示所述文件系统对象是否是在一可信客户机上创建的，第二位(L)指示一不可信客户机是否可以访问所述文件系统对象。

3.如权利要求1或2中所述的方法，进一步包括根据所述用户ID、客户机ID和文件系统对象，从包括根用户、可信客户机上的所有者、不可信客户机上的所有者、可信客户机上的组成员、不可信客户机上的组成员以及其他用户的列表判定请求用户类型。

4.如权利要求3中所述的方法，其中所述允许访问文件系统对象的步骤包括检查与请求用户的类型对应的扩展访问权限。

5.如上述任一权利要求中所述的方法，其中所述扩展访问权限进一步包括所有者模式位、可信客户机上的组模式位以及其他模式位。

6.如权利要求5中所述的方法，其中所述允许进一步包括当所述请求用户为根用户并且所述客户机ID对应于一可信客户机时，授权所述请求用户访问。

7.如权利要求5或6中所述的方法，其中所述允许访问文件系统对象的步骤进一步包括当所述请求用户为一可信客户机上的所有者时，根据所述所有者模式位授权访问。

8.如权利要求5、6或7中所述的方法，其中所述允许访问文件系统对象的步骤进一步包括当所述请求用户为一不可信客户机上的所有者，并且所述文件系统对象是在一不可信客户机上被创建时，根据所述所有者模式位授权访问。

9.如权利要求5、6、7或8中所述的方法，其中所述允许访问文件系统对象的步骤进一步包括当所述请求用户为一不可信客户机上的所有者，所述文件系统对象是在一可信客户机上创建并且不允许一不可信客户机访问所述文件系统对象时，根据所述其他模式位授予访问权限。

10.如权利要求5至9中的任一权利要求中所述的方法，其中所述允许访问文件系统对象的步骤进一步包括当所述请求用户类型为不可信客户机上的所有者，允许一不可信客户机访问所述文件系统对象，并且所述客户机ID出现于所述文件系统对象的inode中时，根据所述所有者模式位授权访问。

11.如权利要求5至10中的任一权利要求中所述的方法，其中所述允许访问文件系统对象的步骤进一步包括当所述请求用户的类型为不可信客户机上的组成员时，根据所述其他模式位授权访问。

12.如权利要求5至11中的任一权利要求中所述的方法，其中所述允许访问文件系统对象的步骤进一步包括当所述请求用户的类型为可信客户机上的组成员时，根据所述可信客户机上的组成员模式位授权访问。

13.如权利要求5至12中的任一权利要求中所述的方法，其中所述允许访问文件系统对象的步骤进一步包括当所述用户为其他用户时，根据所述其他模式位授权访问。

14.一种用于在分布式文件系统中提供访问的系统，所述系统包括：

用于存储文件系统对象的存储器；

用于执行以下操作的处理设备：

检索请求用户的用户ID和客户机ID；

判定所述客户机ID对应于可信客户机还是不可信客户机；

获取文件系统对象的扩展访问权限，其中所述扩展访问权限指示所述文件系统对象是否是在一可信客户机上创建的以及一不可信客户机是否可以访问所述文件系统对象；以及

根据所述用户ID、客户机ID和文件系统对象的扩展访问权限允许访问所述文件系统对象。

15.如权利要求14中所述的系统，其中第一位(T)指示所述文件系统对象是否是在一可信客户机上创建的，第二位(L)指示一不可信客户机是否可以访问所述文件系统对象。

16.如权利要求14或15中所述的系统，其中可信客户机和不可信客户机的列表存储在所述存储器中。

17.如权利要求16中所述的系统，其中所述可信客户机的列表包括具有唯一用户ID的所有客户机。

18.如权利要求14中所述的系统，其中可信和不可信客户机可根据可信计算进行判定。

19.如权利要求14中所述的系统，其中授权的可信客户机的列表存储在所述文件系统对象的inode中。

20.如权利要求14至19中的任一权利要求中所述的系统，其中所述用户ID是用户ID和客户机ID的组合。

21.如权利要求14至20中的任一权利要求中所述的系统，进一步包括用于根据所述用户ID、客户机ID和文件系统对象，从包括根用户、可信客户机上的所有者、不可信客户机上的所有者、可信客户机上的组成员、不可信客户机上的组成员以及其他用户的列表判定请求用户的类型的装置。

22.如权利要求21中所述的系统，其中允许访问文件系统对象包括检查与请求用户的类型对应的扩展访问权限。

23.如权利要求14至22中的任一权利要求中所述的系统，其中所述扩展访问权限进一步包括所有者模式位、可信客户机上的组模式位以及其他模式位。

24.如权利要求23中所述的系统，其中所述允许进一步包括当所述请求用户为根用户并且所述客户机ID对应于一可信客户机时，授权所述请求用户访问。

25.如权利要求23或24中所述的系统，其中允许访问文件系统对象进一步包括当所述请求用户为一可信客户机上的所有者时，根据所述所有者模式位授权访问。

26.如权利要求23、24或25中所述的系统，其中允许访问文件系统对象进一步包括当所述请求用户为一不可信客户机上的所有者，并且所述文件系统对象是在一不可信客户机上创建时，根据所述所有者模式位授权访问。

27.如权利要求23、24、25或26中所述的系统，其中允许访问文件系统对象进一步包括当所述请求用户为一不可信客户机上的所有者，所述文件系统对象是在一可信客户机上创建的并且不允许一不可信客户机访问所述文件系统对象时，根据所述其他模式位授权访问。

28.如权利要求23至27中的任一权利要求中所述的系统，其中允许访问文件系统对象进一步包括当所述请求用户类型为一不可信客户机上的所有者，允许一不可信客户机访问所述文件系统对象，并且所述客户机ID出现于所述文件系统对象的inode中时，根据所述所有者模式位授权访问。

29.如权利要求23至28中的任一权利要求中所述的系统，其中允许访问文件系统对象进一步包括当所述请求用户的类型为一不可信客户机上的组成员时，根据所述其他模式位授权访问。

30.如权利要求23至29中的任一权利要求中所述的系统，其中允许访问文件系统对象进一步包括当所述请求用户的类型为一可信客户机上的组成员时，根据所述可信客户机上的组成员模式位授予访问权限。

31.如权利要求23至30中的任一权利要求中所述的系统，其中允许访问文件系统对象进一步包括当所述用户为其他用户时，根据所述其他模式位授权访问。

32.一种计算机程序，包括当所述程序运行于计算机上时，适于执行权利要求1至13中的任一权利要求中的方法的程序代码装置。

Images