文件和目录的访问控制(3) 访问规则

简介:

文件和目录的访问控制(3) 访问规则

访问规则有两种类型:“允许allow)和拒绝deny)。可以通过检查规则的AccessControlType属性来确定相应规则的类型。按照约定,拒绝规则总是优先于允许规则。因而,如果向某个对象中添加下列两个规则:授予每个人读、写访问权限拒绝Xuanhun写访问权限,则Xuanhun将被拒绝进行写访问。

想要枚举文件或者目录的访问规则时,可以使用如代码清单7-11所示的方式。

7-11  枚举文件访问规则

class Program

    {

        static void Main(string[] args)

        {

            string path = @"e:\AclTest\acltest.txt";

                FileSecurity security = File.GetAccessControl(path);

                foreach (FileSystemAccessRule rule in

                    security.GetAccessRules(true, true, typeof(NTAccount)))

                {

                    Console.WriteLine("{0} {1}---- {2}",

                        rule.AccessControlType == AccessControlType.Allow ?

                        "授权" : "拒绝",rule.IdentityReference.ToString(),

                        rule.FileSystemRights

                        );

                }

           

            Console.Read();

        }

    }

以上代码使用File类的GetAccessControl方法获取FileSecurity对象,然后通过FileSecurity类的GetAccessRules方法获取当前文件的访问规则。对于目录的操作与此基本类似,相应地,使用的是DirectorySecurity对象。

GetAccessRules方法有三个参数:第一个参数表示是否要包括为对象显式设置的访问规则;第二个参数表示是否要包括继承的访问规则;第三个参数表示访问规则的类型。代码清单7-11的运行结果如图7-9所示。

 

 

7-9 枚举文件访问规则的运行结果

为方便起见,访问规则被公开为集合。该集合是只读的,因此对它的规则进行的所有修改都必须通过FileSecurity对象的专用方法(例如AddAccessRuleSetAccessRuleRemoveAccessRule)执行。集合内部的规则对象也是不可改变的。要了解为什么拒绝规则优先于允许规则,必须知道访问检查算法是如何工作的。当执行访问权限检查时,将按照规则在访问控制列表内部出现的顺序对它们进行评估。在代码清单7-11中,当检查用户Xuanhun的访问权限时,会首先评估拒绝Xuanhun读取访问的规则,然后再评估授予BUILTIN\Everyone读取和执行访问权限的规则。一旦做出允许或拒绝的决策,评估就将停止。这就是拒绝规则生效的原因。如果它们被放置在允许规则之后,则它们不会总是执行它们的预期功能。

和可以添加新的访问规则一样,还可以移除现有的访问规则。但是注意,在从用户那里撤回某项权限和完全拒绝该权限之间存在差异。例如,假设Xuanhun全职雇员组的成员,并且被设置为:全职雇员可以读取文件“Xuanhun具有读写访问权限。根据这一方案,撤消Xuanhun的读取权利会产生下列规则:全职雇员可以读取文件“Xuanhun具有写入访问权限。这恐怕不是您所期望的结果,因为撤消Xuanhun的读取访问权限没有产生任何效果:Xuanhun仍然可以作为全职雇员获得读取访问权限。如果你的目标是确保不会将访问权限授予Xuanhun,达到该目标的唯一方式是添加一个拒绝规则。此外,如果该对象根本不包含任何访问规则,那么每个人都将被拒绝对该对象的所有访问权限。

继承

我们只考虑了不具有子对象的简单的叶子对象。一旦从叶子对象(例如文件、信号量和互斥锁)转向容器对象(例如目录、注册表项和Active Directory容器),事情就变得复杂了。额外的复杂性源自以下事实:容器的访问规则可能被配置为不仅应用于对象本身,而且还应用于它的子对象、子容器或这两者。这就涉及继承和传播设置的领域。

每个访问规则不是显式的就是继承的(用IsInherited属性来确定),显式规则是那些已经通过在对象上执行的显式操作添加到该对象的规则;相反,继承规则来自于父容器。在使用对象时,只能操纵它的显式规则。

在向容器中添加新的显式规则时,可以指定两组标志:继承标志和传播标志。继承标志有两个:容器继承(Container InheritCI)和对象继承(Object InheritOI)指定容器继承的规则将应用于当前容器对象的子对象,对象继承规则应用于叶子子对象。当传播标志被设置为None时,这些关系是可传递的:它们将跨越当前容器下层次结构的整个子树,并且应用于该容器的子对象、孙子对象等。

规则的顺序是很重要的,因为它确定了优先顺序,并最终影响到对象的访问方式。尽管无法更改默认顺序,但明白一组规则将被授予哪个类型的访问权限是很重要的。最重要的是,所有继承规则总是跟在显式规则后面。这样,显式规则总是优先于继承规则,父规则优先于祖父规则,等等。

父对象和子对象

如果希望对象避开由其父对象给予它的安全语义,会发生什么情况呢?实际上,确实存在可以声明我的父对象的安全设置将不再适用于我的机制。此时,甚至可以指定是否希望在该情况下使继承规则保持原样,但是在父对象的设置发生更改时拒绝侦听,另外,可以彻底清除所有继承规则。这是通过访问控制保护实现的,如代码清单7-12所示:

  7-12 访问控制保护

using(FileStream file = new FileStream(

  @"M:\temp\sample.txt", FileMode.Open, FileAccess.ReadWrite))

{

   

   FileSecurity security = file.GetAccessControl();

 

    security.SetAccessRuleProtection(

   true,

       false );

    file.SetAccessControl(security);}

以上代码中需要说明的是SetAccessRuleProtection方法,该方法设置或移除与此ObjectSecurity 对象关联的访问规则的保护。受保护的审核规则不会通过继承被父对象修改。它的第一个参数标识访问规则是否被继承,如果为true则不被继承,否则继承。第二个参数标识是否保留继承的访问规则,如果保留为true,去除则为false

注意 尽管可以使用该技术避免从父对象那里收到继承设置,但没有办法收到父对象不打算给予你的继承设置,传播只会发生在其ACL没有受到保护的对象上。可以做的唯一事情就是在父对象改变主意之前获得继承设置的快照,因为一旦访问规则受到保护,它们就将保持这个状态,并且父对象无法重写它们。

所有者

 “所有者owner)的概念对于对象安全性是很特殊的。所有者被赋予了特殊的权力,即使与对象相关联的规则禁止用户访问该对象,但如果该用户是所有者,则他仍然可以重写现有规则,并重新获得对该对象的控制。完成该操作的过程与访问规则的常规操作过程没有什么不同。安全对象还允许更改所有者,但是操作系统将禁止其他人执行该操作。通常,为了更改所有者,必须具有对象的TakeOwnership权限或者具有特殊的取得所有权Take Ownership)特权更改所有者如下所示(假设你具有这样做的权利):

FileSecurity security = file.GetAccessControl();

security.SetOwner(new NTAccount(@"Administrators\Xuanhun"));

file.SetAccessControl(security);

以上代码中使用SetOwner方法来制定当前文件的所有者为NTAccount类型用户Xuanhun

此外,还可以查看对象的当前所有者是谁,或者请求将所有者作为安全标识符或Windows NT账户对象返回,如以下代码所示:

SecurityIdentifier sid = (SecurityIdentifier)security.GetOwner(typeof(SecurityIdentifier));

Console.WriteLine(sid.ToString());

NTAccount nta = (NTAccount)security.GetOwner(typeof(NTAccount));

Console.WriteLine(nta.ToString());

以上代码使用两种形式来查看所有者:一种是SecurityIdentifier对象,另一种是NTAccount对象。SecurityIdentifier表示一个安全标识符 (SID) 并为 SID 提供封送处理和比较操作。NTAccount表示一个用户或组账户。


本文转自玄魂博客园博客,原文链接:http://www.cnblogs.com/xuanhun/archive/2012/06/23/2559588.html,如需转载请自行联系原作者

相关实践学习
云安全基础课 - 访问控制概述
课程大纲 课程目标和内容介绍视频时长 访问控制概述视频时长 身份标识和认证技术视频时长 授权机制视频时长 访问控制的常见攻击视频时长
目录
相关文章
|
8月前
|
运维 监控 网络协议
【运维知识进阶篇】集群架构-Nginx常用模块(目录索引+状态监控+访问控制+访问限制)(下)
【运维知识进阶篇】集群架构-Nginx常用模块(目录索引+状态监控+访问控制+访问限制)(下)
58 0
|
8月前
|
运维 监控 应用服务中间件
【运维知识进阶篇】集群架构-Nginx常用模块(目录索引+状态监控+访问控制+访问限制)(上)
【运维知识进阶篇】集群架构-Nginx常用模块(目录索引+状态监控+访问控制+访问限制)
62 0
|
4月前
|
算法 数据安全/隐私保护 流计算
信道划分&介质访问控制&ALOHA协议&CSMA协议&CSMA/CD协议&轮询访问MAC协议
信道划分&介质访问控制&ALOHA协议&CSMA协议&CSMA/CD协议&轮询访问MAC协议
194 1
|
数据安全/隐私保护 流计算
计算机网络:随机访问介质访问控制之CSMA协议
计算机网络:随机访问介质访问控制之CSMA协议
164 0
计算机网络:随机访问介质访问控制之CSMA协议
|
数据安全/隐私保护
【计算机网络】数据链路层 : 轮询访问 介质访问控制 ( 轮询协议 | 令牌传递协议 )
【计算机网络】数据链路层 : 轮询访问 介质访问控制 ( 轮询协议 | 令牌传递协议 )
344 0
|
缓存 安全 测试技术
详细解析工作流Activiti框架中的LDAP组件!实现对工作流目录信息的访问控制和维护
本片文章介绍了工作流Activiti框架在企业中应用的场景,也就是集成LDAP使用,通过将Activiti框架连接企业的LDAP实现对企业用户和群组信息的管理。文章从用法,用例,配置,属性几个方面分别详细说明了Acitivi集成LDAP使用的具体方式。
217 0
详细解析工作流Activiti框架中的LDAP组件!实现对工作流目录信息的访问控制和维护
|
Cloud Native 关系型数据库 Java
PolarDB-X 1.0-用户指南-访问控制-激活PolarDB-X访问RDS服务授权
PolarDB-X的部分操作会调用RDS的OpenAPI,因此在使用RAM之前,需要先激活PolarDB-X访问RDS服务的授权,创建一个供PolarDB-X访问RDS的RAM服务角色。本文将介绍如何通过控制台和OpenAPI激活授权。
169 0
PolarDB-X 1.0-用户指南-访问控制-激活PolarDB-X访问RDS服务授权
|
数据安全/隐私保护 C++
派生类的访问控制和类型兼容规则
派生类继承了基类的全部数据成员和除了构造、析构函数之外的全部函数成员,但是这些成员的访问属性在派生的过程中是可以调整的。从基类继承的成员,其访问属性由继承方式控制。 基类的成员可以有 public、protected 和 private 三种。基类的自身成员可以对基类中任何一个其他成员进行访问,但是通过基类的对象就只能访问该类的公有成员。
265 0
|
安全 Java 数据管理
基于角色访问控制RBAC权限模型的动态资源访问权限管理实现
前面主要介绍了元数据管理和业务数据的处理,通常一个系统都会有多个用户,不同用户具有不同的权限,本文主要介绍基于RBAC动态权限管理在crudapi中的实现。RBAC权限模型(Role-Based Access Control)即:基于角色的权限控制。模型中有几个关键的术语: 用户:系统接口及访问的操作者 权限:能够访问某接口或者做某操作的授权资格 角色:具有一类相同操作权限的用户的总称 。 #### 用户角色权限关系 一个用户有一个或多个角色 一个角色包含多个用户 一个角色有多种权限 一个权限属于多个角色
665 0
基于角色访问控制RBAC权限模型的动态资源访问权限管理实现
|
Kubernetes 数据安全/隐私保护 容器
kubernetes RBAC实战 kubernetes 用户角色访问控制,dashboard访问,kubectl配置生成
kubernetes RBAC实战 环境准备 先用kubeadm安装好kubernetes集群,[包地址在此](https://market.aliyun.com/products/56014009/cmxz022571.
2071 0