Home Sign In

Steven Van de Craen's Blog [MVP]

Bloggings about SharePoint, .NET and more.

MVP SharePoint Server

RSS Feed
  • Contact Me

Archives

July 2007 (19)
August 2007 (5)
April 2008 (4)
September 2007 (3)
November 2007 (12)
October 2007 (4)
December 2007 (8)
January 2008 (6)
February 2008 (3)
March 2008 (4)
June 2008 (3)
July 2008 (1)
August 2008 (2)
September 2008 (2)
October 2008 (5)
November 2008 (3)
December 2008 (5)
January 2009 (1)
March 2009 (1)
April 2009 (2)
May 2009 (1)

Categories

  • SharePoint 2003
  • SharePoint 2007
  • General
  • Office 2003
  • Office 2007
  • Excel Services
  • Dynamics NAV
  • SOAP
  • Search
  • Search Server 2008
  • .NET
  • CKS
  • IIS
  • VBA
  • Forms Server
  • SharePoint Updates

Recent Posts

  • Event Receivers on Content Types
  • SharePoint 2007: Update system properties (Created, Created By, Modified, Modified By)
  • MVP Renewal 2009
  • Advanced Computed Field
  • Crawling custom document properties on a file share

Other Blogs

//BLOG: naked programmer
JOPX
Jan Tielens' Bloggings [MVP]
Serge van den Oever [Macaw]
Carlos Segura Sanz
Remco Ploeg's Blog
SharePoint Blogs
Romeo Pruno
Andrew Connell [MVP MOSS]
Mark Harrison
Pedro Serrano
Clemens Vasters and the Indigettes
Kevin Boske
SharePoint Team Blog
Brian Jones: Office XML Formats
Mart Muller's Sharepoint Weblog
Joel Oleson's SharePoint Land
Kris' blog
STSADM Custom Extensions
Microsoft Enterprise Search Blog
Michaël's coding thoughts
Chris O'Brien's blog
John Holliday's SharePoint Reflections
Koen's blog
PDT IT Services Blog Posts
Mike Walsh's WSS and more
Patrik Luca's Blog
deyaert's blog

Item-level permissions: 'Only their own'

The title of this blog post is referring to this screen in the List Settings:

It interests me because it

  • allows you to control ownership of the item
  • is only available to Lists but not to Document Libraries
  • doesn't use unique permissions but some other mechanism

One thing it mentions is that it only works for users without Manage Lists permission on the list. So even if I manage to unravel its' secrets it isn't a waterproof solution (compared to unique item permissions for example). Still, if SharePoint has the notion of ownership it is definitely worth a closer look ! Maybe there's an opportunity here ?

It definitely isn't security by obscurity; if I navigate directly to an item that's not mine I still can't access it.

Peeking under the hood reveals that this setting is stored in SPList.ReadSecurity and SPList.WriteSecurity. Those MSDN articles contain all the details so I'll try not to be repetitive

ReadSecurity

Possible values:

  • 1 - All users have Read access to all items.
  • 2 - Users have Read access only to items that they create.

WriteSecurity

Possible values:

  • 1 — All users can modify all items.
  • 2 — Users can modify only items that they create.
  • 4 — Users cannot modify any list item.

What about Document Libraries ?

For a Document Library these properties always have a value of "1" meaning everyone has read and write access (provided their permission level is sufficient). Since there is no interface in the Library Settings they cannot be changed. However nothing is stopping me from writing a few lines of code to update the settings, is there ?

using (SPSite site = new SPSite("http://moss/demo1"))
{
     using (SPWeb web = site.OpenWeb())
     {
          SPList list = web.Lists["Shared Documents"];
          list.ReadSecurity = 2;
          list.WriteSecurity = 2;
          list.Update();
     }
}

Guess what ? It worked fine in the standard SharePoint Views and queries but not for WebDAV (Explorer View, etc). Probably the reason they only use it on SharePoint Lists.

An opportunity ? Not really since it doesn't act as real security in all scenario's. At least my curiosity is satisfied.

 
Categories: .NET, Search Server 2008, SharePoint 2007

Trackback Url

 

Comments

Monday, 5 Jan 2009 11:48 by Michaël Hompus
This is really a bad implemented by WSS. First: it works like SPS2003, if you are allowed to see other items, but only to modify your own you will be able to choose edit/delete on other people's items. Only to be confronted by a security error/log on as different user screen. So it breaks the 2007 pattern that things you're not allowed to do are not available. Second: if you use the object model you are allowed to delete other items!!! This is even worse, suggesting that the security is not implemented on the object model, but in the user interface layer. This corresponds to your findings about the webdav lack of respect for these settings. I hope MOSS 14 will be better on this point, because it is a nice feature to the user.

Thursday, 15 Jan 2009 10:33 by James Turton
Interesting post. @Michaël: It would be a bit unfortunate - list security that can be set through the API but is not subsequently enforced by it. Perhaps it's mitigated by the fact that you can only call the API from code running on the server, but I wonder about lists.asmx...

Friday, 13 Feb 2009 08:12 by Mehul Bhuva
Hi Steven, i am a regular follower of your blog, and have interesting take aways each time i visit your site. I have developed a new utility just to address this issue, It is a simple Windows Form Application that allows users to manage Read Write Permissions for any type of List or Document Library in Sharepoint You can download it from here: http://www.codeplex.com/ListSecurityManager

Friday, 27 Mar 2009 08:31 by Dan Luciano
This post may have saved me some grief. Thanks a bunch. I had a list that somehow got the WriteSecurity value set to 2 and it was overwriting our item level security being applied by a custom event receiver. I was able to use powershell to reset the value and fix the bug. Still, need to monitor to find what rogue process made that change. I will post and link back. Cheers!

Leave a comment

Name

Url

Email

Comments

CAPTCHA Image Validation

© 2007 Steven Van de Craen — Powered by Community Kit for SharePoint: Enhanced Blog Edition.