Access control for files and directories (3) Access rules

There are two types of access rules: Allow (allow) and deny (Deny). You can determine the type of the rule by examining the AccessControlType property of the rule. By convention, a rejection rule always takes precedence over the allowed rule. Thus, if you add the following two rules to an object: "Grant Everyone read, write access," and "Deny Xuanhun Write access", Xuanhun will be denied write access.

When you want to enumerate the access rules for a file or directory, you can use the way shown in Listing 7-11.

7-11 Enumerating file access rules

Class program
    
    {
    
        static void Main (string[] args)
    
        {
    
            string path = @ "E:\AclTest\acltest.txt";
    
                FileSecurity Security = File.getaccesscontrol (path);
    
                foreach (FileSystemAccessRule rule on security
    
                    . Getaccessrules (True, True, typeof (NTAccount)))
    
                {
    
                    Console.WriteLine ("{0} {1}----{2}", Rule
    
                        . AccessControlType = = Accesscontroltype.allow?
    
                        " Authorization ":" Refusal ", rule. Identityreference.tostring (), Rule
    
                        . Filesystemrights
    
                        );
    
                }
    
               
    
            Console.read ();
    
        }
    
    

The code above uses the GetAccessControl method of the file class to get the FileSecurity object, and then obtains the access rules for the current file through the Getaccessrules method of the FileSecurity class. The operation of the directory is basically similar to this, and correspondingly, the DirectorySecurity object is used.

The Getaccessrules method has three parameters: the first parameter indicates whether you want to include an access rule that is explicitly set for the object, the second parameter indicates whether you want to include an inherited access rule, and the third parameter represents the type of access rule. The results of listing 7-11 run as shown in Figure 7-9.

7-9 enumerating the running results of file access rules

For convenience, access rules are exposed as collections. The collection is read-only, so all modifications to its rules must be performed through the FileSecurity object's proprietary methods, such as Addaccessrule, Setaccessrule, and Removeaccessrule. The Rule object within the collection is also immutable. To understand why a rejection rule takes precedence over an allowable rule, you must know how the access checking algorithm works. When you perform access permission checks, they are evaluated in the order in which they appear within the access control list. In Listing 7-11, when you check the access rights of a user Xuanhun, the rules that deny Xuanhun read access are evaluated first, and then the rules that grant Builtin\everyone read and execute access are evaluated. Once a decision is made that allows or refuses, the assessment is halted. This is why the rejection rule "takes effect." If they are placed after the allowed rule, they do not always perform their intended function.

You can also remove existing access rules, just as you can add new access rules. Note, however, that there is a difference between recalling a permission from the user and completely rejecting the permission. For example, suppose Xuanhun is a member of the full-time employees group and is set to: Full time employees can read files and Xuanhun have read and write access. Under this scenario, revoking read rights for Xuanhun produces the following rules: "Full-time employees can read files" and "Xuanhun have write access." This is probably not the result you expected because the undo Xuanhun read access has no effect: Xuanhun can still get read access as a full-time employee. If your goal is to ensure that access is not granted to Xuanhun, the only way to achieve that goal is to add a rejection rule. In addition, if the object does not contain any access rules at all, everyone will be denied all access to the object.

Inherited

We only consider simple leaf objects that do not have child objects. Once you move from a leaf object (such as a file, semaphore, and mutex) to a container object (such as a directory, registry key, and Active Directory container), things get complicated. The additional complexity stems from the fact that the access rules for a container may be configured to apply not only to the object itself, but also to its child objects, child containers, or both. This involves the realm of inheritance and dissemination settings.

Each access rule is either explicit or inherited (as determined by the IsInherited property), and explicit rules are those that have been added to the object by an explicit operation performed on the object; instead, the inheritance rules come from the parent container. When you use an object, you can only manipulate its explicit rules.

When you add a new explicit rule to a container, you can specify two sets of flags: inheritance flags and propagation flags. There are two inheritance flags: Container Inheritance (Container inherit,ci) and object Inheritance (objects Inherit,oi). Specifies that the rules for container inheritance apply to child objects of the current container object, and object inheritance rules apply to leaf child objects. These relationships are transitive when the propagation flags are set to none: They will span the entire subtree of the hierarchy under the current container, and apply to the container's child objects, grandchild objects, and so on.

The order of the rules is important because it determines the order of precedence and ultimately affects how the object is accessed. Although it is not possible to change the default order, it is important to understand which type of access permissions a set of rules will be granted. Most importantly, all inheritance rules are always followed by an explicit rule. In this way, the explicit rule always takes precedence over the inheritance rule, the parent rule takes precedence over the grandfather rule, and so on.

Parent objects and child objects

What happens if you want the object to avoid the security semantics given to it by its parent object? Indeed, there is a mechanism for declaring that the security settings of my parent object will no longer apply to me. At this point, you can even specify whether you want the inheritance rule to remain the same in that case, but deny "listening" when the parent object's settings change, and you can completely purge all inherited rules. This is done through access control protection, as shown in Listing 7-12:

7-12 Access Control Protection

using (FileStream file = new FileStream (
    
  @ "M:\temp\sample.txt", FileMode.Open, FileAccess.ReadWrite))
    
{
    
       
    
   FileSecurity Security = file. GetAccessControl ();
    
     
    
    Security. Setaccessruleprotection (
    
   True,
    
       false);
    
    File. Setaccesscontrol (security);}

The Setaccessruleprotection method that you need to describe in the preceding code sets or removes the protection of the access rules associated with this ObjectSecurity object. Protected audit rules are not modified by the parent object through inheritance. Its first parameter identifies whether the access rule is inherited or not, if true, or inheritance. The second parameter identifies whether to preserve inherited access rules, or False if left to true.

Note Although you can use this technique to avoid receiving inheritance settings from the parent object, there is no way to receive inherited settings that the parent object does not intend to give you, and propagation will only occur on objects whose ACLs are not protected. The only thing you can do is to get a snapshot of the inherited settings before the parent object changes, because once the access rules are protected, they will remain in that state and the parent object cannot override them.

Owner

The concept of owner is special for object security. The owner is given special powers, even though the rules associated with the object prohibit the user from accessing the object, but if the user is the owner, he can still override the existing rule and regain control of the object. The process of completing this operation is no different from the general procedures for accessing the rules. The security object also allows the owner to be changed, but the operating system prevents others from performing the operation. In general, in order to change the owner, you must have the TakeOwnership permission for the object or have a special "get Ownership" (Take ownership) privilege to change the owner as follows (assuming you have the right to do so):

FileSecurity Security = file. GetAccessControl ();

Security. SetOwner (The new NTAccount (@ "Administrators\xuanhun"));

File. Setaccesscontrol (security);

The SetOwner method is used in the above code to make the owner of the current file the NTAccount type user Xuanhun.

You can also see who the current owner of the object is, or request that the owner return as a security identifier or a Windows NT account object, as shown in the following code:

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

Console.WriteLine (SID. ToString ());

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

Console.WriteLine (NTA. ToString ());

The above code uses two forms to view the owner: one is the SecurityIdentifier object and the other is the NTAccount object. The SecurityIdentifier class represents a security identifier (SID) and provides marshaling and comparison operations for SIDS. The NTAccount class represents a user or group account.

Author: Hyun-Soul

Source: http://www.cnblogs.com/xuanhun/

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/net/