Access Denied w/Impersonate=true

Discussion in 'ASP .Net Security' started by Rich Yadach, May 25, 2004.

  1. Rich Yadach

    Rich Yadach Guest

    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 stylesheet,
    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.
     
    Rich Yadach, May 25, 2004
    #1
    1. Advertising

  2. 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" <> wrote in message
    news:...
    > 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 stylesheet,
    > 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.
    >
    >
     
    Andrea D'Onofrio [MSFT], May 26, 2004
    #2
    1. Advertising

  3. Rich Yadach

    yadman Guest

    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]" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    > > 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 stylesheet,
    > > 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.
    > >
    > >

    >
    >
     
    yadman, May 26, 2004
    #3
  4. Is giving Everyone Full Control a sound solution? Isn't this bypassing
    pinning down the appropriate permission settings and setting access rights
    appropriately?

    "Andrea D'Onofrio [MSFT]" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    > > 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 stylesheet,
    > > 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.
    > >
    > >

    >
    >
     
    Raymond Lewallen, May 26, 2004
    #4
  5. I'm sorry but I didn't mean use MUST use Everyone full control to to solve
    your issue.
    The best things to do is to set the appropriate permission settings, this is
    because I've sent the article link: specifically for the temp folder you
    must have the read/write access for the process account. This is
    configuration dependent: the default is aspnet, but if you use impersonation
    and Windows Integrated/Basic/Digest Authentication all the requester users
    MUST have this grant. In this this case you can create a domain group and
    grant the read/write access to this group.
    If you use the Anonymous authentication you must grant the read/write access
    to this account configured in IIS (default is IUSR_MachineName).

    HtH,
    Andrea

    --
    This posting is provided "AS IS" with no warranties, and confers no rights.

    "Raymond Lewallen" <> wrote in message
    news:%...
    > Is giving Everyone Full Control a sound solution? Isn't this bypassing
    > pinning down the appropriate permission settings and setting access rights
    > appropriately?
    >
    > "Andrea D'Onofrio [MSFT]" <> wrote in message
    > news:...
    > > 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" <> wrote in message
    > > news:...
    > > > 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 stylesheet,
    > > > 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.
    > > >
    > > >

    > >
    > >

    >
    >
     
    Andrea D'Onofrio [MSFT], May 28, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kathy Burke
    Replies:
    3
    Views:
    2,691
    Kathy Burke
    Dec 22, 2003
  2. Natty Gur
    Replies:
    0
    Views:
    486
    Natty Gur
    Dec 22, 2003
  3. rockdale
    Replies:
    2
    Views:
    541
    rockdale
    Nov 28, 2006
  4. bdb112
    Replies:
    45
    Views:
    1,403
    jazbees
    Apr 29, 2009
  5. Bill Belliveau

    DirectoryEntry Impersonate or WindowsIdentity Impersonate?

    Bill Belliveau, Jan 28, 2004, in forum: ASP .Net Security
    Replies:
    3
    Views:
    391
    Joe Kaplan \(MVP - ADSI\)
    Jan 31, 2004
Loading...

Share This Page