SharePoint Permission Inheritance
By: Rob Fisch | Updated: 2010-01-27 | Comments | Related: > Sharepoint
I am just getting started with SharePoint and noticed many security options and features. I can see that you can attach named users to sites, lists and libraries. I can even see there is some type of grouping system. But I don't know what to make of it all.
SolutionBeginning with WSS3 (and MOSS 2007), Microsoft introduced a security system that was granular right down to the item level. This means that not only can sites, lists and libraries be configured with different security setups, but individual list and document items within a library or list can have unique permission setups.
Before exploring the details of SharePoint security, it is important to understand the concept of permission inheritance. Permission inheritance occurs every time a new SharePoint object is created. All SharePoint objects are created within the context of a hierarchical tree. By default, all SharePoint objects 'inherit' the permissions of it's parent object until you change the inheritance structure.
Let's walk through some steps of creating objects, showing the inheritance, and then editing the inheritance to show the granular possibilities for SharePoint security.
To begin I'll create a new site. (Site Actions --> Create Site)
Here is where we get our first important option. The default is to "Use same permissions as parent site". This does what you think. However there is no flexibility at all in the new site. I recommend always starting a new site with unique permissions unless you have a specific reason to use the default.
In WSS3 and MOSS 2007, the next important choice is on the next screen. The questions are what default groups do you want for the site. By default, the group choices are a group each for:
- Read only
- Contribute permissions (read and write)
- Owners (full control).
I usually except the defaults, however I change the title of the 2nd group from 'members' to 'contributors'. It's a subtle difference in terminology, but it keeps me from going nuts guessing exactly what constitutes the permission of a "member", which is a little vague.
So the site gets created. Let's look at some of the default settings.
After clicking on "People and Groups", we can see three groups available . Two (xxxxx Contributors, and xxxxx Owners) were created when the site was built. The "RobFisch.com Visitors" group I chose to 'inherit' when the site was built. (By clicking 'More...' you can access other groups in the site collection.)
Let's take a look at the advanced security settings of the site. Click "Site Actions" and then "Site Settings".
Under "Users and Permissions" click "Advanced permissions".
Here are the default site settings that we chose when creating the site.
When new site objects (like document libraries or other lists) are created, they will "inherit" these settings by default. Let's create a new document library and take a look. Click "Site Actions" then "Create".
After choosing "Document Library", enter a name and accept all the default values and click "Create".
Now let's check the default permissions on the document library. In the library settings, click "Permissions for the document library".
Notice they are the same as the default site permissions.
After creating a folder, let's take a look at the 'inherited' permissions.
Yep, same as the document library (which inherited from the site).
After creating a new folder, let's change things around. In the permission settings of the new folder there is an "Action" menu. Select "Edit Permissions" from the menu.
Here is were we get to stop the inheritance and create a different set of permissions from it's parent object. Take a look at the warning message below...
After clicking "OK" we see there are now check boxes next to each permission objects. At this point we can remove or edit any of the permission objects.
To remove a permission, check one (or more) of the boxes and select "Remove User Permissions" from the "Actions" dropdown.
Here is the result.
Whenever we change permissions at any level, all objects created underneath that level inherits the new permission set. So for a particular folder in a library where you modified the permissions, all documents in the library will inherit the permissions of the folder. Though I did not demonstrate it, you can change document permissions in the same was as a folder permission. So if there is a particularly sensitive document in the folder, you can hide it from a set of users while showing it to a different set of users.
SharePoint permission inheritance provides a way of automating some administrative tasks while offering granular control, much like a file server.
- Check out MSSQLTips.com for great information about Microsoft SQL Server.
Last Updated: 2010-01-27
About the author
View all my tips