Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Permissions problem with writeable directory (for cacheing)

  Asked By: Ravi    Date: Jun 19    Category: Sharepoint    Views: 938

I have created a web part that loads binary files (stored as byte
arrays in a varbinary column in SQL Server 2005) and displays them,
either as a link for download, or in a 3rd party control
(WebImageViewer, from Atalasoft). The WebImageViewer control requires
a caching folder with writeable permissions. When loading an image
into the WebImageViewer control, it immediately (in the background)
writes out the image to the cacheing folder, and then displays the
image from the cache.

I had this working in an earlier incarnation as a user control
running with SmartPart. At that time, I had created a subdirectory
path within the particular Sharepoint web application (the default
VirtualDirectories/80) as /UserControls/ImageCache, and given
read/write permissions on these folders to the AppPool identity. In
that incarnation, the Atalasoft DLLs were in the bin directory.

Now, I have redeveloped this as a web part. Since I no longer have
user controls, I just have an /ImageCache subdirectory. I am
deploying the DLLs to the GAC instead of the bin, and using a wsp
solution file to deploy everything. I am running on Minimal_Trust.

Also, I have lots of other web parts which DON'T require write
permissions on a folder. These web parts are working correctly, so I
am quite sure that my general SafeControls web.config settings are
correct.

The problem is that when WebImageViewer loads an image and then goes
to write it to the ImageCache folder, a 4011 event code occurs (see
EventViewer details, below). I have been trying to fix this for 2
days, and am stumped. The user write permissions appear to be the
same as before, and all the DLLs involved in this process are in the
GAC. (I also briefly tried FullTrust, it didn't resolve this!) What
am I missing?

Share: 

 

6 Answers Found

 
Answer #1    Answered By: Heena Nagori     Answered On: Jun 19

My question would be where is the dll for the 3rd party image viewer
going? My suspicion is that since that's the dll that actually writes
to the cache that's the one that is causing the security exception.

 
Answer #2    Answered By: Aishwarya Karmarkar     Answered On: Jun 19

I've placed both my webparts DLL, as well as all of the Atalasoft
DLLs (including the one containing the web  viewer controls) into the
GAC.

Actually, I have one other piece of information that may help. For
non-image files  (eg. pdfs) I just provide a link button that, when
clicked, calls an event handler that downloads a byte array. Rather
than call the database every time, I write these to the cache for
reuse. This process is similar, but doesn't involve the 3rd party
DLL. It also worked OK with SmartPart, but is now failing with my web
part. In this case, the exception is thrown on the FileStream write
method, with the exception:

"Access to the path 'C:\Inetpub\wwwroot\wss\VirtualDirectories\80
\ImageCache\learning.pdf' is denied."

Does that help locate the problem?

 
Answer #3    Answered By: Janell Camacho     Answered On: Jun 19

A co-worker suggested following the permissions  trail of the folder
using ProcMon.exe (downloaded from Microsoft). Once I did so, I found
the culprit: My app pool identity WAS configured correctly. However,
the following line was set to true in the web.config:

<identity impersonate="true" />

Our site is using forms authentication with
AspNetSqlMembershipProvider. Since impersonate was set to true,
therefore the anonymous identity was attempting the write (and, of
course, failing). Once I turned off identity impersonate, write was
successful.

Read still failed, because read went to anonymous access. I could
resolve this by setting "Read" only permission on the anonymous
identity for this folder.

Remaining questions:
1) What is the default Sharepoint web.config setting for <identity
impersonate> (this dev machine has been in use for awhile, I don't
recall setting this entity)? Does Sharepoint require identity
impersonate = true by default? (It seems to defeat the app pool, so
I'm not sure why it would.)

2) When using forms authetnication, is giving "Read" only permission
to the anonymous identity for an image cache directory  considered a
bad security practise? I would only consider doing this because Read
is NOT using the app pool identity.

Any suggestions?

 
Answer #4    Answered By: Julia Washington     Answered On: Jun 19

On a windows authenticated site the impersonate should be set to true.
SharePoint might work with it set to false, but most webparts assume it
is set to true. When you want to do something in a webpart as the App
Pool account you should do it by running in elevated privileges. That
uses the App pool identity account. That is even more true with FBA
based sites since normally there is no windows account to impersonate.
Check out the following MSDN video.

msdn2.microsoft.com/en-us/library/bb466220.aspx

 
Answer #5    Answered By: Shashwat Takle     Answered On: Jun 19

It looks like I'm HALF there with writing to an ImageCache
directory, using the default identity impersonate on anonymous user,
with Forms-Based Authentication, using elevated privileges (as you
recommended.)

One case works, the other, fails.

1) in the first case, I write my own code, including a
FileStream.Write() method. I have wrapped this code as follows, and
IT WORKS:

SPSecurity.CodeToRunElevated codeToRun = new
SPSecurity.CodeToRunElevated(MyMethod);
SPSecurity.RunWithElevatedPrivileges(codeToRun);

2) in the 2nd case, I am relying on a 3rd party control that performs
its own writes to the cache. I HAVE wrapped ALL of my interaction
with the control, including setting of properties, Open() method, and
the CreateChildControls and RenderContents logic:

this.Controls.Add(webImageViewer);
AND
webImageViewer.RenderControl(writer);

However, it is failing, and I am guessing this is because code that
the 3rd party control ITSELF runs (such as writing to the ImageCache)
doesn't fall under the CodeToRunElevated logic, above.

Is there a way to place the ENTIRE control and its logic within
elevated privileges?

 
Answer #6    Answered By: Aastha Acharya     Answered On: Jun 19

The only way I can think of to do that would be to subclass their
control by inheriting from it. Not sure if that would work either, not
even sure they left the classes as inheritable.

Other than that I don't know of a way to do it