This project is read-only.

How to fix the Log4net related SecurityException, discuss it!

Feb 6, 2011 at 11:17 PM


I'm really amazed that how many exceptions are being thrown by various components within the system. Since exceptions are costly I was digging into one of them related to Log4Net.

This is the exception that happens for every request which is using the logging module, during log4net initialization:

log4net:ERROR XmlConfigurator: Failed to initialize configuration file watcher for file [C:\Workspace\CleanGold\Main\Src\Tombarany Orchard\src\Orchard.Web\log4net.config]
System.Security.SecurityException: Request failed.
   at log4net.Config.XmlConfigurator.ConfigureAndWatchHandler..ctor(ILoggerRepository repository, FileInfo configFile)
   at log4net.Config.XmlConfigurator.ConfigureAndWatch(ILoggerRepository repository, FileInfo configFile)
The action that failed was:
The type of the first permission that failed was:
The Zone of the assembly that failed was:

This exception raised because the LoggingModule only registers the type for Log4netFactory and the ILoggerFactory interface and not an instance.

Log4netFactory's default constructor is initializing with "log4net.config" filename, which in our case will be checked within the root of the website. This kind of initialization is not picking up the log4net.config value from the appSettings of our web.config, which is problem #1.

Problem #2 is that this default implementation of Log4netFactory is configuring XmlConfiguration with a FileInfo object and when the XmlConfiguration class is accessing it's FullName property the SecurityException raised. It's our "luck" that XmlConfigurator has an override which takes a StreamReader or one which takes a XmlElement (more on this later).

Problem #3 is that XmlConfigurator is initialized by the default implementation with ConfigureAndWatch (SecurityException number n raised here for the same reason), which installs a FileSystemWatch handler for log4net's config file. For me it's a no brainer, since we are using Log4Net per HTTP Request, and it's very unlikely that someone will tamper the config during a HTTP request, or if someone does I don't think that we should handle that situation in our scenario, so the plain Configure method should be enough for us since a file system watcher is just system resource wasting!

Problem #4 for me is a performance point of view that XmlHierarchyConfigurator is forcing the environment variable expansion for all properties and does not remember if the previous expansion failed, the other one that it calls Environment.GetEnvironmentVariables() for each property and also not caching this list. Taking into account a big Orchard site and lot of concurrent users I think that these things can cause performance problems. I'm wondering what should be the performance difference on if this error get a fix!

So if we like to get rid of this error we have some possible solution at our disposal! We should just pick one!

Since in my terms this is a bug, but needs to discussion with the team and peers on how to fix it, that's why I started this as a discussion and not a bug.


Feb 8, 2011 at 7:31 PM

Thanks for investigating this. Seems like good points. I would file a bug (or even better one per problem) and refer to this discussion from there. It also seems like you have a good grasp on what the fix would be. Would you consider contributing patches?



Feb 8, 2011 at 11:17 PM

Ok, of course I'll file the bugs about the problems and if you agree the proposed fixes I’ll take the time to do that sometime soon!

Orchard is something that’s worth investing into :-)

During this investigation I had to dig into Castle project sources also for the log4net integration and I found out that Orchard is using a very-very old castle release. It's not the problem that we're not on 2.5 which is new, but from the 1.x versions only 1.2 is available now, so at least we should update to those bits. I was not able to find the accompanying sources for the used Castle release.

Does updating to 1.2 has any breaking changes? I don't think so, I'll give it a try if you agree to move to that version as the LAST 1.x release.


What about 2.5 update? Any thoughts tries on that?




Feb 8, 2011 at 11:42 PM

The problem is that we have made modifications to Castle (I think for medium trust in particular). So you'd need to either reproduce those modifications or upgrade to something that already has them. André or Louis would know the details on this.

Feb 21, 2011 at 8:33 PM

Any status update on this one?
I'm seeing the same 1000 security exceptions

Feb 21, 2011 at 8:41 PM

I don't remember seeing any bug getting logged. @attilah, should I just log your findings myself?

Feb 21, 2011 at 8:41 PM

I don't remember seeing any bug getting logged. @attilah, should I just log your findings myself?

Feb 21, 2011 at 8:44 PM

Sorry I was a little bit off and overhelmed with other things, I’ll log the bug these days if that’s ok!

From: bertrandleroy [email removed]
Sent: Monday, February 21, 2011 9:42 PM
To: Hajdrik Attila
Subject: Re: How to fix the Log4net related SecurityException, discuss it! [orchard:244881]

From: bertrandleroy

I don't remember seeing any bug getting logged. @attilah, should I just log your findings myself?

Sent from Exchange Server 2010
Feb 21, 2011 at 8:45 PM

Fantastic, thanks!

Mar 8, 2011 at 8:37 PM

I added a bug (#17453), submitted the fix and made pull request for this.

I've solved all the points above.

Mar 9, 2011 at 10:54 PM

We've taken Attila's fix for this as a contribution.

Thanks Attila!