So we've been getting this Access Denied exception when creating MOSS 2007 sites in certain scenarios and its been kicking us in the happy place. To top it off, we've done a good bit of custom code that has been deployed and has caused similar Access Denied issues. We have since fixed our own custom code issues but just the fact that we had done custom stuff muddied the waters and had us going in 100 different directions when this latest problem came up.
Here is the scenario we saw this issue appear:
- Create a site collection, I'll call it "SC1"
- Add some site collection admins and some users.
- Create a sub site under SC1 that does not inherit permissions, I'll call It "SubSite1"
- Add some users and create the site
- After the site is created, add a unique user that has "full control" on this site. Make sure the user has NO rights to the site collection SC1. I'll call him "SubSiteFullControl1"
- Log into SubSite1 as user SubSiteFullControl1
- Attempt to create a sub site from SubSite1
- We get Access Denied when you click the "Create" button on the form (newsbweb.aspx). Even though he has full control on the site.
Searching through the MOSS log files we see the following two error messages:
CreateSitePanel1: An exception occured in OnFormSave(). Exception: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex) at Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException(UnauthorizedAccessException ex) at Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish) at Microsoft.SharePoint.SPListItem.AddOrUpdateItem(Boolean bAdd, Boolean bSystem, Boolean bPreserveItemVersion, Boolean bNoVersion, Boolean bMigration, Boolean bPublish, Boolean bCheckOut, Boolean bCheckin, Guid newGuidOnAdd, Int32& ulID, Object& objAttachmentNames, Object& objAttachmentContents, Boolean suppressAfterEvents) at Microsoft.SharePoint.SPListItem.UpdateInternal(Boolean bSystem, Boolean bPreserveItemVersion, Guid newGuidOnAdd, Boolean bMigration, Boolean bPublish, Boolean bNoVersion, Boolean bCheckOut, Boolean bCheckin, Boolean suppressAfterEvents) at Microsoft.SharePoint.SPListItem.Update() at Microsoft.SharePoint.Portal.SiteAdmin.CreateSitePanel1.AddItemToList(SPWeb web) at Microsoft.SharePoint.Portal.SiteAdmin.CreateSitePanel1.OnFormSave(Object objOfInterest)
DelegateControl: Exception thrown in OnFormSave() method of child control for ControlId='CreateSitePanel1'. Exception: System.Threading.ThreadAbortException: Thread was being aborted. at Microsoft.SharePoint.Portal.SiteAdmin.CreateSitePanel1.OnFormSave(Object objOfInterest) at Microsoft.SharePoint.WebControls.DelegateControl.CallFormSaveForChildren(Object objOfInterest)
Isn't that a nice little ditty. The short answer is it's trying to add a list item to some kind of share point list and getting blocked. We assumed that it must be at the Site Collection level since the user we are logged in as has no rights there, but we could not figure out WHY it would be trying to do this.
As it turns out, at the Site Collection level you can check a box that says "Enforce listing new sites in Site Directory" (Located in SiteSettings->SiteDirectorySettings). That little punk is the culprit. If that is checked, every site that is created will attempt to add a new list item in the directory, REGUARDLESS of whether or not the user creating the site has rights too!!!
Un-checking that box will fix the problem. Obviously MSFT needs to fix this as it's a totally valid case to have sub-web admins/full control users that don't have access to the site collection they belong too. Simply running the list item addition with elevated privileges would fix the problem. Here's hoping it's fixed in SP1.
No comments:
Post a Comment