Basic policies and principles for setting NTFS permissions in Windows XP

Set NTFS permissions basic policies and principles

In Windows XP, there is a cardinal to the management of permissions, that is, rejection is superior to the principle of permission, the principle of privilege minimization, the principle of accumulation and the principle of permission inheritance. This cardinal will play a very important role in the setting of permissions, and here's a look at:

Rejection is preferable to the principle of consent

The principle of "refusal is better than permission" is a very important and fundamental principle, it can perfectly handle the rights "disputes" caused by the user's attribution to the user group, for example, "Shyzhong", which belongs to both the "shyzhongs" user group and the "Xhxs" user group, when we The "Shyzhong" account in this group automatically has write permission when a resource in the XHXS group is assigned a centralized allocation of write permissions (that is, for a user group).

But surprisingly, the "Shyzhong" account clearly has the "write" permission on this resource, why the actual operation is not implemented? Originally, the "Shyzhong" user was also granted permission for this resource in the "Shyzhongs" group, but the permission set is " Write denied. " Based on the principle of "deny is better than allow", "Shyzhong" permission to be "denied write" in the "Shyzhongs" group takes precedence over the permission given in the "Xhxs" group to allow "write" permission to be executed. Therefore, in practice, the "shyzhong" user cannot write to this resource.

The principle of Privilege minimization

It is essential that Windows XP implement "keep the user's minimum permissions" as a basic principle. This principle ensures maximum security for resources. This principle makes it possible for users to be unable to access or unnecessarily access resources to be given restrictions by valid permissions.

Based on this rule, in the actual permission-giving operation, we must explicitly give the resource permission to allow or deny operations. For example, the new restricted user "Shyzhong" in the system does not have any permissions on the "DOC" directory by default. Now you need to give this user permission to read for the "Doc" directory, then you must add a read for "Shyzhong" user in the "Doc" Directory's permissions List Permissions

The principle of permission inheritance

The permissions inheritance principle makes it easier to set permissions on resources. Suppose you now have a "DOC" directory with subdirectories such as "DOC01", "DOC02", "DOC03" in this directory, and now you need to set the "Shyzhong" User with write permission on the DOC directory and the subdirectories under it. Because of the inheritance principle, only the "DOC" directory Setting "Shyzhong" User has write permission, and all subdirectories under it will automatically inherit this permission's setting.

Cumulative principle

This principle is better understood, assuming that the "Zhong" user now belongs to the "A" user group, also belongs to the "B" user group, where the permissions of the A user group are read and the permissions in the "B" user group are "write", then the actual permissions of the "Zhong" user will be "read + write" based on the cumulative principle.

Obviously, the "deny better than allow" principle is used to resolve conflict issues on permissions settings; " The principle of "privilege minimization" is used to guarantee the security of resources; The permission inheritance principle is for Automation to execute permission settings, and the cumulative rule is to make permissions more flexible. Several principles are used, the lack of which will give permission to set up a lot of trouble!

Note: In Windows XP, all members of the "Administrators" group have the "Get owner" (Take ownership) power, where members of the Administrators group can "seize" their identities from other users, such as restricted users. Shyzhong "Set up a doc directory, and only give yourself read power, this seemingly thoughtful permission settings, in fact, the" Administrators "group of all members will be able to" capture ownership "and other methods to obtain this permission.

Cancel Everyone Full Control permission

Select the file or folder for which you want to revoke permissions, right-click on the attribute, locate the "Everyone" Ace in the ACL under the Security tab, select Edit, and remove the check before the "Full Control" permission.

Effects of copying and moving folders on permissions

In the application of permissions, it is unavoidable to encounter situations where resources need to be replicated or moved after the permissions have been set, so what will happen to the corresponding permissions of the resource at this time? Here's a look at:

(1) When replicating resources

When a resource is replicated, the permissions of the original resource do not change, and the newly generated resource inherits the permissions of the parent resource in its destination location.

(2) When moving resources

When you move a resource, there are generally two situations where the object retains its original permissions (including the resources themselves and the permissions previously inherited from the parent resource) if the resource movement occurs within the same drive, and the second is that if the resource movement occurs between different drives, Not only will the permissions of the object itself be lost, but the permissions that were previously inherited from the parent resource will be replaced by the permissions inherited from the parent resource in the target location. In fact, the move operation is the first to replicate the resources, and then delete the resources from the original location of the operation.

(3) Non-NTFS partitions

The permission changes that are generated when you copy or move resources above are only for NTFS partitions, and if you copy or move resources to a non-NTFS partition, such as a FAT16/FAT32 partition, all permissions are automatically lost.