Cannot upload to a permissions-enabled document library even with RunWithElevatedPrivileges

Question

In our WSS 3.0 application, we have a document library that has an elevated folder called "Approved". It has different permissions from the rest of the Document Library in order to prevent people from normal access to it for uploads or editing. The only entities that have full access to that folder are an Administration group, including myself.

However, we do have a scenario where it is necessary to upload straight to it. I devised a simple ASPX page with a FileUpload control, which then uses SPSecurity.RunWithElevatedPrivileges (in itself inside of a SPLongOperation) to attempt an upload to that folder. If I run it, the thing runs smoothly, the file is uploaded, everything is green. But whenever one of our engineers tries it, they get an "Access Denied" error for having insufficient privileges.

This is despite running the entire thing inside of the elevated privileges of the System Account, and an extra measure I took to remove the original uploading user entirely from the equation and pretend it was the System Account. I don't understand why this is failing, as for all intents and purposes the System Account is running everything and it has sufficient privilege to post in that library (and does so in a workflow that can be triggered by any user at a different stage in the process!)

Below is the code that I use inside of the SPSecurity.RunWithElevatedPrivileges block. It's a very simple upload code, and yet it seems to be insufficient. Am I missing some security bits or anything? Am I going about it wrong?

using (SPSite site = new SPSite(webUrl))
{
    using (SPWeb web = site.OpenWeb())
    {
        bool oldAllow = web.AllowUnsafeUpdates;
        try 
        {
            SPList l = web.Lists[_targetList];
            SPFile file;

            int tID = int.Parse(hdIdent.Value);
            SPListItem task = web.Lists["Tasks"].GetItemById(tID);

            int targetID = int.Parse(hdRef.Value);
            SPListItem target = web.Lists[_targetList].GetItemById(targetID);

            web.AllowUnsafeUpdates = true;

            //Grab file from the FileUpload control "upDrawing"
            System.IO.Stream fStream;
            byte[] contents = new byte[upDrawing.PostedFile.InputStream.Length];
            fStream = upDrawing.PostedFile.InputStream;
            fStream.Read(contents, 0, (int)fStream.Length);
            fStream.Close();

            //Original values are in comments, switched to the System Account
            //in case this was the cause, but it still fails.
            SPUser u1 = siteAdmin; //target.GetSPUser("Created By");
            SPUser u2 = siteAdmin; //currentUser;

            file = web.Files.Add(webUrl + "/" + _targetList + "/Approved/" + upDrawing.FileName, contents, u1, u2, (DateTime)target["Created"], DateTime.Now);
            target = web.Lists[_targetList].GetItemById(targetID);
            target["File Flag"] = 1;
            target.NonfiringUpdate();
        }
        finally
        {
            web.AllowUnsafeUpdates = oldAllow;
        }
    }
}

Answer 1

Have you tried:

l.RootFolder.Files.Add(l.RootFolder.Url + "/Approved/" + upDrawing.FileName, contents )

Answer 2

Check the permissions on the "Tasks" list as well as whatever list _targetList is pointing to in order to verify that the engineers have at least 'contribute' permissions there. FWIW, you are also fetching 'target' twice.

You should enable detailed error messages in order to identify the exact line that is failing

Answer 3

Instead of creating a new SPSite object from the URL, can you retrieve it from a current context? I see it's an aspx page, use SPContext? I read somewhere when you create a new site object you get permissions of the current user and not the admin account.

Otherway to test, since this is an aspx page, access the page when logged in as a admin user (Site Collection Admin/System Account) and then try upload. Does it go through?

I'll try and look up the references.

Edit: Please ignore the suggestion in first paragraph. The current implementation quoted in the original question is correct with respect to use of 'RunWithElevatedPrivileges'. Following article highlights it http://blog.bugrapostaci.com/2010/04/28/sharepoint-runwithelevatedprivileges-and-access-denied-error/

The only addition I can suggest is using Site-wide AllowUnsafeUpdates.

Answer 4

we're having the same problem..

Grace Note, the reason why SPSecurity.RunWithElevatedPrivileges does not work because you have to create SPSite & SPWeb inside that elevated block again.

If you're using an instance of spweb/spsite that is created outside RunWithElevatedPrivileges block, then the objects are not elevated. so in that case it does not matter if you try to cal files.add(..) inside the elevated block..

in our case, we're trying to add a file programaticall in a event receiver. If the user is contributor, even though he/she has the upload right we got "access denied" error.. creating an elevated site/web instance in event receiver is a bad practice so we're mostly stuck on that.

any updates ?