Blogging catchup and mailbox spring clean

jasbro — Fri, 07 Mar 2008 03:50:00 GMT

Having recently spent some time in India attending training on Microsoft Search Server 2008, and having been quite sick as a result, I've got a bit of a backlog of SharePoint blogging to catch up with. First of all, to comment on Search Server: This is a great product. It significantly builds on the search already offered by WSS and MOSS, streamlines the admin and search interface, adds Ajax functionality and Federation, and comes in a free Express flavour to boot. This is a new, standalone product, but you could potentially also look on it as an expansion/update for your current WSS 3.0 installation. An update for MOSS adding this functionality will be available on a provisional timeframe of mid-2008 (calendar).

MOSS administrators, you may be aware that SQL Database maintenance can be the bane of your existence, as well as being something of a dark art with documentation having been thin on the ground. The good news is that there is now a whitepaper covering all aspects of DB maintenance for SharePoint. Download it here and get cracking on supported database maintenance scenarios.

Securing MOSS is a large topic deserving of more than just a throwaway line on a blog, so I intend to develop some content on the subject in the coming weeks, as workload allows. For now, here's the Roadmap to Security Content for Office Sharepoint Server 2003, which should be on any admin's bookmark list.

Unfortunately, I'm short on time to post much more than this for now, but expect more in the near future...

SPSecurity.RunWithElevatedPrivileges()

jasbro — Wed, 12 Dec 2007 03:09:00 GMT

The subject of today's post: running code in sharepoint with elevated rights, an operation sometimes required, sometimes abused and often misunderstood.

The WSS Object Model provides a huge number of classes, some of which can carry-out potentially dodgy actions, so require elevation to run. Ordinarily you'd just deal with this by logging in as a user with rights to carry out the operation, but occasionally this isn't practical or possible, and that's where today's subject comes in.

Let's say, just as an example, you're creating an anonymously-accessible site. In a Control on on of the pages you want to enumerate subsites of your site, and grab some properties thereof, maybe for display, maybe for some other operation in your code - however, this isn't something an anonymous identity can do.

In steps our hero - RunWithElevatedPrivileges()

Used correctly, this method allows a specified block of code to run in the context of the SharePoint System Account, a powerful method with much potential. Here's the summary from the SDK:

[SharePointPermissionAttribute(SecurityAction.Demand, Impersonate=true)] [SharePointPermissionAttribute(SecurityAction.Demand, ObjectModel=true)] public static void RunWithElevatedPrivileges ( CodeToRunElevated secureCode )

Now the CodeToRunElevated parameter can be a reference to a void, parameterless method or an anonymous method via delegate() - please, follow the SDK link if that's unclear.

Pretty simple, huh? Yep, well as always there's a catch or two.

1. If you're manipulating any Object Model elements within your elevated method, you need to get a fresh SPSite reference inside this call. For example

SPSecurity.RunWithElevatedPrivileges(delegate(){ SPSite mySite = new SPSite(http://sharepoint/); SPWeb myWeb = SPSite.OpenWeb(); // further implementation omitted });

2. You can't just use SPContext.Current.Site to get your SPSite reference - or you'll ber handed the object with the security context of the anonymous (or non-elevated) user and your elevation will not work as expected.

3. If you need to Update() anything inside this block, you'll need to call SPSite.AllowUnsafeUpdates() on your new site reference (or web reference) as per this SDK entry.

So those are the gotchas. Following those we have the obvious security warnings - be careful what you do within this call, as the system identity has full control over SharePoint and could do Very Bad Things if incorrectly used. Sanitise any user input very carefully if you're going to let it anywhere near this method - you certainly don't want a user finding some injectable exploit into this code. Exercise caution over what you do, for this power must be used wisely. But you knew that, right?

Just Another Web Application : security

Blogging catchup and mailbox spring clean

SPSecurity.RunWithElevatedPrivileges()