Re: Access Denied w/Impersonate=true

From: yadman (ryadach_at_travelers.com)
Date: 05/26/04 

Date: Wed, 26 May 2004 12:41:19 -0400

Thanks for the reply.

I agree, this is a potential solution, however, our company does not allow
ANYONE access (not even read) to the C: drive. Is there was a way to
configure the temp folder (and drive) that would be best. Is that possible?

"Andrea D'Onofrio [MSFT]" <andreado@online.microsoft.com> wrote in message
news:u2pEqJzQEHA.964@TK2MSFTNGP10.phx.gbl...
> 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.
> >
> >
>
>