Re: Access Denied w/Impersonate=true

From: Andrea D'Onofrio [MSFT] (andreado_at_online.microsoft.com)
Date: 05/26/04 

Date: Wed, 26 May 2004 17:01:57 +0200

The error says that the user doesn't have permission to access to the temp
folder. Using impersonate=true the user identity is the identity of the user
that opens the browser.
Please, check this article
http://support.microsoft.com/default.aspx?kbid=317012#4 in order to check
the permission needed.
Probably you may solve your problem setting for Everyone Full control on the
Temp folder.

HtH, 

-- 
This posting is provided "AS IS" with no warranties, and confers no rights.
"Rich Yadach" <ryadach@travelers.com> wrote in message
news:u0delWoQEHA.1160@TK2MSFTNGP09.phx.gbl...
> Does anyone have any ideas or comments on this?
>
>
>
> The problem seems to stem from having Impersonate=True set in our
web.config
> files (Version 1.1).
>
>
>
> Here is the error we encountered .
>
>
>
> The actual filename changes every time you try to load the page:
>
> An error has occurred: Access to the path
> "C:\DOCUME~1\servername\ASPNET\LOCALS~1\Temp\olvtg0lf.0.vb" is denied.
>
>
>
> This is what I grabbed from the server's event viewer:
>
> 1) Exception Information
>
> *********************************************
>
> Exception Type: System.UnauthorizedAccessException
>
> Message: Access to the path
> "C:\DOCUME~1\servername\ASPNET\LOCALS~1\Temp\olvtg0lf.0.vb" is denied.
>
> TargetSite: Void WinIOError(Int32, System.String)
>
> HelpLink: NULL
>
> Source: mscorlib
>
>
>
> StackTrace Information
>
> *********************************************
>
>    at System.IO.__Error.WinIOError(Int32 errorCode, String str)
>
>    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess
> access, FileShare share, Int32 bufferSize, Boolean useAsync, String
msgPath,
> Boolean bFromProxy)
>
>    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess
> access, FileShare share)
>
>    at System.CodeDom.Compiler.CodeCompiler.FromDomBatch(CompilerParameters
> options, CodeCompileUnit[] ea)
>
>    at System.CodeDom.Compiler.CodeCompiler.FromDom(CompilerParameters
> options, CodeCompileUnit e)
>
>    at
>
System.CodeDom.Compiler.CodeCompiler.System.CodeDom.Compiler.ICodeCompiler.C
> ompileAssemblyFromDom(CompilerParameters options, CodeCompileUnit e)
>
>    at System.Xml.Xsl.Compiler.CompileAssembly(ScriptingLanguage lang,
> Hashtable typeDecls, String nsName, Evidence evidence)
>
>    at System.Xml.Xsl.Compiler.CompileScript(Evidence evidence)
>
>    at System.Xml.Xsl.Compiler.Compile(NavigatorInput input, XmlResolver
> xmlResolver, Evidence evidence)
>
>    at System.Xml.Xsl.XslTransform.Compile(XPathNavigator style***,
> XmlResolver resolver, Evidence evidence)
>
>    at System.Xml.Xsl.XslTransform.Load(String url, XmlResolver resolver)
>
>    at System.Xml.Xsl.XslTransform.Load(String url)
>
>    at UI.Sitemap.PortalSiteMap.TransformXML()
>
>
>
> Here is what the code is doing.simply trying to load an XSL file
>
>
>
> Dim resultsXSLT As New Xsl.XslTransform()
>
> Dim xslFile As new String = "somexslfile..xsl"
>
> resultsXSLT.Load(xslFile)           ß Exception Occurs Here
>
>
>
>                         The xsl file has imbedded within it VBScript.
>
>
>
>
> My theory on what is causing the error.
>
>
>
>                         Since the application code is loading the XSL
file,
> which contains VBScript, I think the CLR is trying to JIT compile the code
> at runtime, and since                            Impersonate=True, is
doing
> this under the security context of the end user.  This user does not have
> access rights to the c:\documents and Setting.                 directory
> listed above.  When we turn Impersonate off everything works because the
> security context is now ASPNET and for version 1.1 of the
> frameworks this account was granted full control of the above mentioned
> directory (see link below).  The reason I think the CLR is trying to JIT
the
> VBScript is when we did some testing I noticed the CLR JIT perfmon
counters
> being incremented when traversing thru this code.
>
>
>
> Here is a link to an identical problem (bet he had impersonate=true):
>
> http://www.dotnet247.com/247reference/msgs/46/231289.aspx
>
>
>
> Not the same situation but does talk about impersonate=true and the
> Documents and Settings Folder:
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;827190
>
>
>
> Question:
>
>
>
>            Can anyone confirm my theory and more importantly is there a
way
> to configure the location of the temp files used for JIT compiles?  I'd
> rather not have to grant our end users full control to the C:\documents
and
> settings. folder when Impersonate=true is set.
>
>
Quantcast