http://sourcedaddy.com/windows-7/file-permissions.html

File Permissions

Owner - simply owns the file, but without permissions the owner is meaningless other than quota purposes. Who gains access is determined by security on files/folders, not ownership.

Security viewed and managed via Properties/Security tab.

Explicitly denying read access takes precedence over any allow permissions.

Basic permissions available for each user or group:- full control - users can modify, add, move, delete files and their associated properties and directories. Users can change permission settings for all files and directories, including ownership.- modify - users can modify files and file properties, including deleting and adding file to directory or file properties to a file.- read and execute - can run executable files, including scripts.- read - can view files and file properties- write - can write to a file

Folders have an additional List Folder Contents permission which allows the objects names in the folder to be traversed.

Deny always takes precedence over an allow. If a user is a member of a group that has permissions to read a file but is also a member of a group that has deny read permissions, the user is able to read the file.If a user is a member of a group that has read permissions and of another group that has modify permissions, the user has both read and modify access.

Special permissions allow more complex combinations of access and control inherited permissions. Inherited means that permissions on a folder are automatically applied to any new object (file/folder) created within. Additional permissions beyond those inherited can be set on an object. This brings an exception to the deny always takes precedence over an allow rule. Inherited permissions have a different order of precedence. Permissions are checked in the following order and when a match for the user is found, the user is either granted or denied access,1. An explicit deny2. An explicit allow3. An interited deny4. An inherited allow

This order means that an explicit allow on a file would override a deny that was inherited. For example, if afolder had deny set for a group and a file within the folder had explicit allow for the group, the members of that group would have access to the file.

To access special permissions, click the Properties/Security tab/Advanced button/Effective Permissions tab. Each permission on the object is displayed, along with whether the permission is explicitly defined on the object or inherited from the parent.

If the Edit button in the Advanced Security Settings dialog is selected, new permissions can be added and existing permissions can be modified and removed. A larger number of options are available if you change permissions via this advanced view. The advanced permission screen is shown. The additional advanced permissions are the following:

- traverse folder/execute file - users can navigate through folders, even if they have no permissions for the traversed files or folders. By default this is not required because the Bypass Traverse Checking user right is assigned via group policy to everyone.- list folder/read data - users can view a list of a folder's contents and data files- read attributes - users can view the attributes, such as read-only and hidden, of a file or folder- read extended attirbutes - users can view the extended attributes of a file or folder- create files/write data - the create files permission applies to folders and allows users to create files within the folder. The write data permission applies to files and allows users to make changes to the specified file and overwrite existing content- create folders/append data - the create folders permission allows users to creaste folders wtihin a folder. The append data permission applies to files only and allows users to make changes to the end of the file, but it does not grant change, delete or overwrite permissions for the existing data- write attributes - users can change the attributes - such as readonly or hidden - of a file or folder- write extended attributes - users can change the extended attributes of a file or folder- delete - users can delete the file or folder- read permissions - users have read permissions on the file or folder- change permissions - users have change permissions on the file or folder- take ownership - users can take ownership of a file or folder. The owner of a file or folder can always change permissions on it, regardless of any existing permissions that protect the file or folder

Along with various security options on an object, you can stop permissions inheritance from an object's parent by unselecting the Include Inheritable Permissions from the Object's Parent check box. If this is uncheched a dialog box is displayed that gives the option to copy or remove the permissions that have been inherited or to cancel the operation altogether.

The final issue with basic permissions is how they work when copying or moving data.If you move a file, its explicit permissions remain. Any inherited permissions are replaced with those of the new parent folder. If you move a folder between volumes, then it is a copy-and-delete operation. Any explicit permissions are lost and the permissions are those inherited from the new parent folder.

If you want to copy a file and maintain its permissions and ownership information, use the XCOPY command with /o switch.

Numerous commands query permissions from the command line. To list all files that a user has permissions defined on, use the icacls command. The icacls has the capability to backup and restore Access Control Lists ACLs on entire directory structure to a file. It can also swap security identifiers SIDs in ACLs or just find all entries that contain a certain SID.

Full information on using the icacls can be found by running icacls /?. Also gives examples.

http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Understanding-Windows-NTFS-Permissions.html

NTFS permissions are available on every file, folder, Registry key, printer and Active Directory object. Windows 2000, XP and 2003 Server are covered here.

Standard permissions

- permissions that control a broad range of detailed permissionsThe most popular standard permission is Full control which everyone wants but very few should get. Full control allows the user to do virtually anything to the object.

Other standard permissions:ModifyRead & ExecuteReadWrite

Folders have the same standard permissions as files, except there is one additional List Folder Contents

Registry keys, printers and Active Directory objects have a totally different set of standrd permissions. The security tab of each object will list the standard permissions, for a typical organizational unit (OU) within Active Directory.

Figure 1: Standard permissions for an OU in Active Directory

Advanced permissions

... are the detailed permissions that are grouped together to create the standard permissions. Since advanced permissions are used in combinations to create the standard permissions, there are more of them overall. Here is a list of advanved permissions for a file:Full controlTraverse folder/Execute fileList folder/Read dataRead attributesRead extended attributesCreate files/Write dataCreate folders/Append dataWrite attributesWrite extended attributesDeleteRead permissionsChange permissionsTake ownership

For example, the advanced permissions that are used to create the Read standard permission includeList folder/Read dataRead attributesRead extended attributesRead permissions

Advanced permissions for a folder are identical to those of a file.However, advanced permissions of a printer or Registry key are completely different. If you want to see the power and control that NTFS 5.0 provides for access control, it is best to investigate the permissions of an OU within Active Directory. Upon first glance, I calculate that you have over 10 000 individual advanced permissions that you can set for an OU, as you can see a partial listing in Figure 2.

Figure 2: Advanced permissions for an OU in Active Directory

Inherited vs Explicit permissions

There are two variations of permissions for any one entry (user, computer or group) listed on the access control list ACL. If we look at the root drive C: you can add or modify the permissions for any entry on the ACL.

If you create a new folder say c:\Data, you won't be able to modify the permissions for any existing entries. This is because the permissions from C: inherit down to all subfolders and files automatically. If you don't want permissions from c: to inherit to c:\data but still want them to inherit down to other subfolders below c:, you could configure c:\data to stop inheriting by removing the check from "Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here" as shown in Figure 3.

Figure 3: You can control inherited permissions on any folder or file

At any level within the resource structure, you can always add new entries to the ACL. These entries, specifically for the target resource, are called explicit permissions, since they are configured directly on the resource. If the default inheritance is enabled for subfolders and files, these explicit permissions will inherit down to subsequent resources, like the original permissions did from C: to c:\data.It is easy to tell the difference between inherited permissions and explicit permissions by the check mark on the permissions for the entry. If the check is not grayed out, the permissions are explicit.

Allow vs Deny permissions

When establishing permissions, you need to specify whether the entry should have access (Allow) or not (Deny) to the resource. The Local Security Authority LSASS then controls the access to the resource, based on the security ID (SID) that you placed on the ACL to the SID placed on the security token that is given to the user at logon. If the SID associated with the user is on the ACL, the LSASS must determine whether the access is set to Allow or Deny. The Allow and Deny permissions inherit down through the structure as described in the section above on inheritance.

You will get warnings from the ACL editor when you create Deny entries, as shown in Figure 4.

Figure 4: Deny entries on the ACL will cause the system to warn you about the limited access you are providing

It is not common to configure resources with Deny permissions, because of the nature of how permissions are evaluated. It is more common to exclude the user or group from the ACL instead of configuring them to have explicit Deny permissions. The fact that the user or group SID is not on the ACL will have the same result of "No access" to the resource, without needing to configure any special entries on the ACL. It is only in the rare instance that a user or group should be explicitly denied access that you configure Deny permissions. Denial of access to resources by omission frm the ACL is easier to troubleshoot, manage and configure.

Permission precedence

I hear all the time, from students to network administrators (even the dialog box in Figure 4) that Deny permissions take precedence over Allow permissions. Unfortunatelly, this is not always the case. To prove my point, let's look at a scenario that you can create to prove that Deny permissions don't always take precedence over Allow permissions.

In our scenario we-re going to look at a folder C:\data\HR which contains both public and private files.We have allowed C:\data\HR to inherit the permissions from c:\data which includes just basic permissions from the root folder.We have also included the HR group on the ACL, giving the Group Allow - Read&Execute permissions. The final explicit entry on the ACL is for the non-HR group, which is given Deny-Full control.

Below the HR folder are two files: Public.doc and Private.docThe Public forlder just allows for normal permission inheritance so there are no special permissions added to the ACL.However, the private file has some explicit permissions added to the ACL. Since the Executive group needs to be able to read the contents of the private folder, this group is added explicitly with the Allow-Read&Execute permission.

Figure 5: Allow permissions can have precedence over Deny permissions

The result of this configuration is shown in Figure 5, which cleraly shows that the Allow permission for the Executive group has a higher precedence than the Deny permission associated witht he non-HR group. Since every executive is included in both groups, you can see that here is a case where Allow permisisons have precendence over Deny permissions.

The scenario proves that there is a hierarchy of permissions for NTFS 5.0 resources. The hierarchy of precedence for the permissions can be summarized as follows, with the higher precedence permissisions listed at the top of the list:

Explicit DenyExplicit AllowInherited DenyInherited Allow

Summary

Permissions are almost the same from Windows NT's NTFS 4.0 to Windows XP's NTFS 5.0.One of the main differenecs is the way that permissions inherit down through the structure with inherited and explicit permissions. It used to be that, if there was a Deny permission on the ACL, it was always evaluated first, then the Allow permissions would follow. Now, the permission hierarchy must be evaluated considering not only the Deny vs. Allow, but whether the permission is explicitly set or inherited down from a parent resource.

END

RUCAK SLIJEDI