EventLogPermission via caspol.exe

[Mark A. Richman]

I am getting an EventLogPermission exception when calling my assembly from an ASP.NET 2.0 app. I tried setting the assembly to FullTrust via caspol.exe, but I still get this exception. Any ideas? I am loading the web app and assemblies over UNC.

 

[Aleksandr Sliborsky]

I am getting an EventLogPermission exception when calling my assembly from an ASP.NET 2.0 app. I tried setting the assembly to FullTrust via caspol.exe, but I still get this exception. Any ideas? I am loading the web app and assemblies over UNC.

Do you use Code Access Security?
May be in some place of Your code You use it declarative.
And You declared that only som signed assemblies can acces Your assembly.
Oh may be You have to use impersonatino because ASP.NET host application
has;t any gihts to access to event log...

Aleksandr Sliborsky

 

[Nicole Calinoiu]

Mark,

What trust level is set for ASP.NET on your machine? (You can check this is
in the %WINDIR%\Microsoft.NET\Framework\v2.0.<build>\CONFIG\web.config
file.) If it's not full trust, then you'll need to ensure that both your
ASP.NET application and your other assembly are granted the necessary
EventLogPermission under the policy specified in the appropriate
web_<level>trust.config file.

That said, writing to the event log from a web application is not
necessarily such a wonderful idea in the first place. If feasible, it might
be a better solution to log to a different target rather than adjusting your
application's permissions to allow writing to the event log.

HTH,
Nicole

 

[Nicole Calinoiu]

Nicole,

Firstly, I am not attempting to log from ASP.NET directly, but from a
dependent assembly (albeit in the same process space - effectively the
same thing, I assume).

Pretty much. When EventLogPermission is demanded from within the .NET
Framework code you are calling, both the ASP.NET application and your
intermediary assembly must have the permission in order for the demand to
pass (at least under "usual" circumstances).

I am loading the web app and assemblies over UNC.
I am also impersonating a Domain Admin account in my web.config.

That's extremely risky. Are you doing this simply for troubleshooting
purposes, or do you plan to run the application under an admin account in
production? If the latter, you may want to reconsider...

My trust
level is the default setting of "Full". I have tried various caspol
commands such as "caspol -m -fulltrust
\\mydomain\dfsroot\dfslink\myapp\bin\myassembly.dll" with no luck.

Chances are good that you're not creating quite the right policy changes
when using caspol. However, before attempting to troubleshoot your caspol
use, have you confirmed that the application runs as expected if the
assemblies reside on the local machine rather than elsewhere on the network?

The full stack trace is as follows (with real names obscured to protect
the innocent):

System.Security.SecurityException: Request for the permission of type
'System.Diagnostics.EventLogPermission, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

at System.Security.CodeAccessSecurityEngine.Check(PermissionToken
permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32
checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission
cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Diagnostics.EventLog.SourceExists(String source, String
machineName)
at System.Diagnostics.EventLog.SourceExists(String source)
at MyException..ctor(Object oSource, Int32 nCode, String sMessage,
Exception oInnerException, Boolean bLog)
at MyAssembly.Foo() in
\\mydomain\dfsroot\dfslink\myapp\App_Code\Blah.cs:line 125
Thank you so much!

--
Mark A. Richman

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
Mark,

What trust level is set for ASP.NET on your machine? (You can check this
is
in the %WINDIR%\Microsoft.NET\Framework\v2.0.<build>\CONFIG\web.config
file.) If it's not full trust, then you'll need to ensure that both your
ASP.NET application and your other assembly are granted the necessary
EventLogPermission under the policy specified in the appropriate
web_<level>trust.config file.

That said, writing to the event log from a web application is not
necessarily such a wonderful idea in the first place. If feasible, it
might
be a better solution to log to a different target rather than adjusting
your
application's permissions to allow writing to the event log.

HTH,
Nicole

 

[Mark A. Richman]

A little update:

The problem was caused by my code being run over UNC vs. local disk. This has the net effect of applying the LocalIntranet_Zone code group as opposed to the My_Computer_Zone, if am correct. I altered the permission set on LocalIntranet_Zone from LocalIntranet to FullTrust and everything works. For production purposes, this may not be the best approach. Not only will my code by running over UNC, but so will my customers' code, and I don't want to grant their code more trust than is necessary (I'm a web hoster). Any suggestions?

Thanks,
Mark

 

[Joe Kaplan \(MVP - ADSI\)]

The generally accepted best way to do this would be to apply strong names to your assemblies so that you can grant them the specific policy settings they need based on their strong name key. You definitely don't want to grant the whole LocalIntranet_Zone these settings and you don't want to grant FullTrust if you can possibly avoid it.

You'll also need to be careful to make sure that the callers of this assembly have the required permissions as the method you are calling does a full demand which causes a full stack walk. Another approach to avoiding that issue would be to ensure that your assembly has permission to Assert and then Assert the permission before you call the method. The Assert will prevent the stack walk and will effectively grant your assembly the right to do the privileged operation, even if this caller doesn't.

Note that giving yourself Assert permissions is something you want to avoid if possible as well as it is a very "blunt instrument" and gives you a lot of power (with which comes great responsibility ).

Nicole will probably have some additional comments, but I hope that gets you started.

Joe K.
A little update:

The problem was caused by my code being run over UNC vs. local disk. This has the net effect of applying the LocalIntranet_Zone code group as opposed to the My_Computer_Zone, if am correct. I altered the permission set on LocalIntranet_Zone from LocalIntranet to FullTrust and everything works. For production purposes, this may not be the best approach. Not only will my code by running over UNC, but so will my customers' code, and I don't want to grant their code more trust than is necessary (I'm a web hoster). Any suggestions?

Thanks,
Mark

 

[Nicole Calinoiu]

As Joe mentioned, using a new code group (preferably under the
LocalIntranet_Zone node) with a strong name membership condition would be
the typical way to handle this type of scenario. However, this is a
somewhat unusual thing to try with ASP.NET, and I'm not quite sure how it
might turn out, particularly in 2.0. If it doesn't work, a code group based
on a URL membership condition would be the next reasonable approach, but
you'll probably need to match the URI format being used by ASP.NET to
retrieve the assemblies, which might mean a bit of trial and error work.

That said, I still find the UNC approach to be a bit odd. Given the dynamic
compilation model used by ASP.NET, I suspect that you might encounter
performance consequences beyond the obvious initial hit. Also, the file
server adds an additional point of potential failure that might affect the
availability of your hosted applications. Why not simply copy the
assemblies to the web server rather than running over UNC?