使用非管理员帐户的 log4Net 事件日志权限问题
这可能不是 SiteCore 本身的问题,但为了完整性我将其包含在内。我使用应用程序池的自定义标识在 IIS7 下运行 sitecore 6.3。我无法让 Sitecore 将其日志记录信息(使用默认的 log4net 设置)写入事件日志。我遵循了这里的建议:http://logging.apache.org/log4net/release/faq.html#Why%20doesn%27t%20the%20EventLogAppender%20work? 虽然当我制作时它工作正常自定义身份管理员组的成员我需要找到一种方法让它在生产中工作而不需要这样的安全黑客。
奇怪的是,我有一个 MSI 安装它(在管理员组成员的帐户下运行)并在事件日志中为我创建正确的注册表项,但尽管如此,我仍然收到以下错误:我使用自定义身份运行应用程序(而不是管理员成员)。
log4net:ERROR DOMConfigurator: Could not create Appender [EventLogAppender] of type [log4net.Appender.EventLogAppender]. Reported error follows.
System.Security.SecurityException: Requested registry access is not allowed.
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at System.Diagnostics.EventLog.GetEventLogRegKey(String machine, Boolean writable)
at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
at System.Diagnostics.EventLog.DeleteEventSource(String source, String machineName)
at log4net.Appender.EventLogAppender.ActivateOptions()
at log4net.Repository.Hierarchy.DOMHierarchyConfigurator.ParseAppender(XmlElement appenderElement)
The Zone of the assembly that failed was:
MyComputer
log4net:ERROR DOMConfigurator: Appender named [EventLogAppender] not found.
我想我可以将其缩小到注册表权限问题,我向每个人授予了以下注册表项和子项的完全权限,但它也不起作用:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
自定义身份是以下组的成员:
- 事件日志读取者
- IIS_USERS
- 性能监视器用户
我还看到了 以下问题这似乎问同样的事情。 Microsoft 文章似乎暗示这可能是事件日志上的 ACL 的问题,并提供了有关如何更改 SSDL 的示例,但如果可能的话,我宁愿避免这种情况。
编辑: 我有另一台服务器正在运行,日志填充得很好。自定义身份是管理员成员,因此我撤销了该身份并重新启动,试图故意破坏它,但我不能。两个盒子上的配置是相同的,并且用于运行创建注册表项的 MSI 的身份相同。在两者上运行 procmon(在执行 IISReset 并再次启动应用程序池之后)以检查注册表活动。奇怪的是 - 在工作的盒子上,您会在错误的位置(应用程序和不同的自定义事件日志“MyCompany”)收到我的事件源的 477 名称未找到记录。记录位置“MyCompany\MyCompany.SiteCore”没有命中。虽然在损坏的盒子上,它似乎确实请求读取正确的密钥(尽管只有 6 次),但随后您会收到 Log4Net 注册表访问错误。
This probably isnt an issue with SiteCore per se but I've included it for completeness. I have sitecore 6.3 running under IIS7 using a custom identity for the app pool. I cant get Sitecore to write its logging information (using the default log4net settings) to the eventlog. I've followed the advice here: http://logging.apache.org/log4net/release/faq.html#Why%20doesn%27t%20the%20EventLogAppender%20work? and although it works fine when I make the custom identity a member of the administrator's group I need to find a way to get it working in production without such a security hack.
The weird thing is that I have a MSI that installs it (running under an account which IS a member of the administrator's group) and creates the correct registry keys in the eventlog for me and yet despite that, I am still getting the following error when I run the application using the custom identity (without it being a member of administrators).
log4net:ERROR DOMConfigurator: Could not create Appender [EventLogAppender] of type [log4net.Appender.EventLogAppender]. Reported error follows.
System.Security.SecurityException: Requested registry access is not allowed.
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at System.Diagnostics.EventLog.GetEventLogRegKey(String machine, Boolean writable)
at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
at System.Diagnostics.EventLog.DeleteEventSource(String source, String machineName)
at log4net.Appender.EventLogAppender.ActivateOptions()
at log4net.Repository.Hierarchy.DOMHierarchyConfigurator.ParseAppender(XmlElement appenderElement)
The Zone of the assembly that failed was:
MyComputer
log4net:ERROR DOMConfigurator: Appender named [EventLogAppender] not found.
Thinking I could narrow it down to a registry permission issue I granted Everyone full permissions to the following registry key and subkeys but it didnt work either: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog
The custom identity is a member of the following groups:
- Event Log Readers
- IIS_USERS
- Performance Monitor Users
I've also seen the following question which seems to ask the same thing. The Microsoft article seems to suggest it might be a problem with ACLs on an event log and gives examples on how you can change SSDLs but I'd rather avoid that if at all possible.
EDIT:
I have another server running where the log is being populated fine. The custom identity was a member of administrators so I revoked that and rebooted, trying to purposely break it but I cant. Config is identical on both boxes and same identity used to run the MSI which creates the registry keys. Have run procmon on both (after doing a IISReset and spinning up the app pool again) to examine registry activity. Strange thing is - on the box that works you get 477 name not found records for my event source in the wrong places (Application, and a different Custom EventLog "MyCompany"). No hits for the place where it is logging which is "MyCompany\MyCompany.SiteCore". Whilst on the box which is broken, it does appear to be requesting to read the right key (albeit only 6 times) but you then get the Log4Net registry access error.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
据我了解,EventStore 存储在注册表中,因此您只需要对注册表的写入权限即可创建或删除 EventStore。这通常只需要一次,并且大多数应用程序将其创建为安装过程的一部分,以便应用程序在正常执行期间不需要以管理员身份运行。
但是,您的错误消息(在问题中)包括方法 DeleteEventSource ,我可以从中推断/猜测 EventSource 确实存在,但在某种程度上是错误的。因此,也许当前已将其注册为写入名为 MyCompany 的事件日志,并且您现在尝试将其更改为“MyCompany\MyCompany.SiteCore”,这要求您删除旧的事件源并创建一个新的事件源。
因此,听起来您的安装例程正在创建一个与您的应用程序实际使用的事件源不同的事件源。
如果这没有帮助,那么我建议启用 Log4net 的内部日志记录 (但显然不是事件日志)这可能会为您提供更多信息。
授予注册表项完全权限是不够的。
根据微软
As I understand it EventStores are stored in the registry, so you only need write permission to registry to create or delete an EventStore. This is usually only needed once and most applications create this as part of the install procedure so that the application does not need to be run as Administrator during normal execution.
However your error message (in the question) includes the method DeleteEventSource from which I would deduce/guess that the EventSource does exist but is wrong in some way. So perhaps this is currently registered as writing to the event log named MyCompany and you are now trying to change it to "MyCompany\MyCompany.SiteCore" which requires you to delete the old eventsource and create a new one.
So it sounds like your installation routine is creating a different EventSource from the one that your application is actually using.
If that doesn't help, then I would suggest enabling internal logging for Log4net (but obviously not to the eventlog) which will probably give you more information.
Giving full permission to the registry key is not enough.
According to Microsoft
我认为,与 Apache 文档,log4net 确实需要对注册表的写访问权限——或者至少在我的情况下是这样。为了证明这一点,我在无法运行的服务器上备份了注册表,并在启动 sitecore 之前授予了 IIS 管理员权限。果然,它开始很好地记录到事件日志中,然后当我再次导出注册表以运行差异时,出现了差异。
我的事件源上的 eventlogmessage 文件的值已从:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
更新为
C:\Windows\Microsoft .NET\Framework64\v2.0.50727\EventLogMessages.dll
所以我认为仅仅手动更改注册表中的这个值就可以了。
但事实并非如此。
所以我在我拥有的两台服务器上运行 procmon:A=工作的服务器,B=故障的服务器。果然,BI服务器上有一行字:
操作:RegOpenKey,路径:HKLM\System\CurrentControlSet\Services\EventLog,所需访问:读/写,结果:访问被拒绝。
我已通过服务器 A 进行追踪在完全相同的位置,使用所需访问权限:读取来请求密钥。
结论:
似乎不可避免的是,我需要在生产中授予我的应用程序池身份管理员权限至少足够的时间,以便第一次从 log4net 中以编程方式执行必要的注册表写入。我不知道为什么管理员;我尝试向我的自定义应用程序的注册表中的整个事件日志节点授予完全权限,但无济于事。它似乎做了一些我无法识别或确定的事情。然后,我将在它开始记录并监视后续安装是否会删除该功能后立即撤销此权限。 (希望不是)。
如果有人对这种行为有任何见解,我们将不胜感激。
I think, contrary to the Apache documentation, log4net DOES need write access to the registry – or at least it does in my case. To prove this, I backed up the registry on the server where it wasnt working and granted IIS administrator privileges before spinning up sitecore. Sure enough it started logging away to the eventlog nicely and then when I exported the registry again to run a diff, there WAS a difference.
The value for the eventlogmessage file on my event source had been updated from:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
To
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll
So I assumed that merely changing this value in the registry by hand would work.
But it didn’t.
So I ran procmon on the two servers I have: A=the working one, B=the failing one. Sure enough, on server B I have a line which says:
Operation: RegOpenKey, Path: HKLM\System\CurrentControlSet\Services\EventLog, Desired Access:Read/Write, Result: ACCESS DENIED.
I’ve traced through with Server A and in exactly the same place, the key is requested with Desired Access:Read.
Conclusion:
It seems unavoidable that I will need to grant my app pool identity administrator privileges in production for at least enough time to programatically do the necessary registry writes the first time from within log4net. I dont know why administrator; I have tried granting Full permissions to the entire eventlog node in the registry for my custom app to no avail. It seems to do something which I cannot identify or pin down. I will then revoke this privilege immediately after it starts to log and monitor whether subsequent installs knock out the functionality afterwards. (Hopefully not).
If anyone has any insight into this behaviour it would be greatly appreciated.