Background
I am currently working on SharePoint integration project and required to understand the security model used in SharePoint in order to get a better and smoother integration with the other systems, the very basic understanding I had was the security in SharePoint is based on ACLs similar to windows, I worked faire way with this assumption until I practically couldn’t achieve the expected result so I decided to get myself dirty and went through the SQL database hacking in order to make myself clear of how it all works.
For those who are wondering, what is ACL, here is a bit of a description. The ACL stands for Access control list and which is a collection of ACEs (Access control entry), the access control entry basically in the windows ACL, mainly contains who or what is allowed or denied access to the given resource and at what level.
To make the subsequent explanation of SharePoint permissions more clear, I will just provide a simple description about the related SQL schema a bit below before the more interesting stuff at the end.
Content database
There are four main tables in the content database that I found important in understanding the access control process in SharePoint. Those are UserInfo, Groups, Perms and Roles tables. Their UserInfo table keeps all the SPUsers including the AD Groups and custom groups by the custom role providers. The groups table keeps all the SPGroups. The Perms table keeps the map of the Acl against the url of the respective list, site or item and the Roles table keeps the permission levels against their respective permission mask. The permission level is explained below.
Representation of the ADAM groups and other custom groups in the UserInfo table behaves quiet different to the AD groups and the explanation of them requires a separate post and that is my next post.
Permissions in SharePoint
In SharePoint there are 33 different permissions possible even though the selection of those permissions are grouped together with the related ones and hence the more granular manual selection is not possible from the SharePoint UI but it is possible by manipulating the permission bit mask by using the SPBasePermissions enum in object model or accessing the SQL tables direct, which I will be explaining in the next section and this process is not a very clean way of doing this so my strong recommendation is not to touch the production versions unless it is badly required for debugging and fixing problems.
Permission levels in SharePoint
Permission levels in SharePoint in my simplistic understanding are a way of grouping of permissions and make the assigning process easier for the SPGroups and SPUsers. The Roles table explains above keeps the permission levels and their respective bit mask for the assign group of permissions.
Access control
This is the main part that I wanted to explain in this post to share the un-document stuff in SharePoint. If you happen to open the content database and open the Perms table you will see the Acl column with a hex byte stream as shown below.
OxF3FE000001000000000000000400000003000000FFFFFFFFFFFFFF7F22000000FFFFFFFFFFFFFF7F23000000FFFFFFFFFFFFFF7F24000000FFFFFFFFFFFFFF7F
First 16 bytes is the header and this contains 4 sets of 4 byte blocks.
F3FE0000010000000000000004000000 => F3FE0000 01000000 00000000 04000000
The 4 th byte tells the number of ACEs in this ACL, I do not have any good guesses for the other bytes but I think there may be a checksum in one of those remaining 3 sets.
03000000
FFFFFFFFFFFFFF7F
According to this ACL, there are 4 ACEs and those 4 ACEs contain 4 sets of 12 bytes. The 12 bytes are also grouped in 3 sets of 4 byte groups. For example the first ACE is shown below.
The first set of 4 bytes represents the unique ID of the corresponding entry (Raw which represents a user or a group) in UserInfo or Groups table in context database and the subsequent 2 sets of 4 bytes represent the bit mask for the SharePoint permissions. There are only 33 permissions available in MOSS 2007 and only the bits given in the SPBasePermissions enum are in use while the other are not in use at least for this version.
Note the bytes in the group of four sets bytes ate arrange in the reverse order and if you happen to look at the Roles table for the bit mask for the respective permission level, you will find it under PermMask column as a big integer.
Conclusion
The access control in SharePoint is purely based on the permissions and permission levels stored in the Roles table. As I mentioned the permission mask for a given permission level is not granular down to the each permission from the SharePoint UI, my understanding for this is to make it more convenient for the users at the user interface level and avoid mistakes but if you need to create your own custom permission level, you could do that in a dirty way by modifying the respective permission mask in SQL database or a slightly a better approach is to use SPBasePermissions enum in object model.
And finally the SharePoint ACL is working purely based on the permission masks, users and groups. The way this ACL works is different from the way Windows ACL works but for the basic concepts, it can be seen as a collection of ACEs
