As mentioned earlier, an item in Windows SharePoint Services can have its own specific permissions. However, default permissions for an item within a site are inherited from that site. This inheritance can be broken for any securable object at a lower level in the site hierarchy by creating a unique permissions assignment for that securable object.
For example, editing the permissions for a document library breaks its permission inheritance from its site. However, the inheritance is broken only for that particular document library; the rest of the permissions for the site remain unchanged. An object can be reverted to inheriting permissions from its parent list or site at any time.
Sites are themselves a securable object to which permissions can be assigned. Sites contained within other sites can be configured to inherit permissions from a parent site or to create unique permissions for that particular site. If a child site inherits permissions from its parent, that set of permissions is shared with the child site. This effectively means that owners of the sites that inherit permissions from a parent site can change the permissions of the parent. To allow control of the permissions for the child site alone, the child site stops inheriting permissions, restricting the owner of the child site to only making changes to the permissions of the child site.
Creating unique permissions for a site stops permission inheritance. The groups, users, and permission levels from the parent site are copied to the child site and then the inheritance is broken. Reverting a site back from unique permissions to inherited permissions causes users, groups, and permission levels to once again be inherited and removes any users, groups, or permission levels that were uniquely defined in the site while inheritance was broken.
Permission levels (roles) can also be inherited. By default, permissions are defined such that the Read permission level is the same regardless of the object to which it is applied. This type of inheritance can also be broken by editing the permission level. For example, an administrator might not require the Read permission level on a particular site (2) to include the Create Alerts permission.
For more information about inheritance, see:
[MSDN-SHPTSDK] for Windows SharePoint Services 3.0
[MSDN-SHPTSDK4] for Microsoft SharePoint Foundation 2010
proc_SecChangeToInheritedWeb and proc_SecChangeToUniqueWeb in [MS-WSSFOB] for Windows SharePoint Services 2.0
proc_SecChangeToInheritedWeb and proc_SecChangeToUniqueScope in [MS-WSSFO] for Windows SharePoint Services 3.0
proc_SecChangeToInheritedWeb and proc_SecChangeToUniqueScope in [MS-WSSFO2] for SharePoint Foundation 2010