非特权用户使用 NHibernate 时无法查询数据库
我使用 Fluent NHibernate 1.2、NH 3.1 和 castle 进行代理生成。我正在尝试以非管理员用户身份运行应用程序(一个简单的 win-forms 应用程序)并看到异常: 无法获取 StrongNameKeyPair 的公钥。
以前(我不确定我做了什么来绕过该步骤),异常是创建代理实例失败。
一些博客2010 年的帖子表明 Castle 的动态代理可能在中等信任场景下存在问题,因此我尝试了 sn -m n
但这似乎没有多大作用。
有人熟悉这种行为吗?
谢谢, JK
编辑:
生成此异常的应用程序调用是 NHibernate 会话上的简单 LINQ。 这是堆栈跟踪的顶部(整个内容大约有 60 行长):
mscorlib.dll!System.Reflection.StrongNameKeyPair.ComputePublicKey() + 0xca bytes
mscorlib.dll!System.Reflection.StrongNameKeyPair.PublicKey.get() + 0x15 bytes
mscorlib.dll!System.Reflection.Emit.AssemblyBuilder.AssemblyBuilder(System.AppDomain domain = {System.AppDomain}, System.Reflection.AssemblyName name = {System.Reflection.AssemblyName}, System.Reflection.Emit.AssemblyBuilderAccess access = Run, string dir = null, System.Security.Policy.Evidence evidence = null, System.Security.PermissionSet requiredPermissions = null, System.Security.PermissionSet optionalPermissions = null, System.Security.PermissionSet refusedPermissions = null, ref System.Threading.StackCrawlMark stackMark = LookForMyCaller, System.Collections.Generic.IEnumerable<System.Reflection.Emit.CustomAttributeBuilder> unsafeAssemblyAttributes = null, System.Security.SecurityContextSource securityContextSource = CurrentAssembly) + 0x4b8 bytes
mscorlib.dll!System.Reflection.Emit.AssemblyBuilder.InternalDefineDynamicAssembly(System.Reflection.AssemblyName name, System.Reflection.Emit.AssemblyBuilderAccess access, string dir, System.Security.Policy.Evidence evidence, System.Security.PermissionSet requiredPermissions, System.Security.PermissionSet optionalPermissions, System.Security.PermissionSet refusedPermissions, ref System.Threading.StackCrawlMark stackMark, System.Collections.Generic.IEnumerable<System.Reflection.Emit.CustomAttributeBuilder> unsafeAssemblyAttributes, System.Security.SecurityContextSource securityContextSource) + 0x7e bytes
mscorlib.dll!System.AppDomain.InternalDefineDynamicAssembly(System.Reflection.AssemblyName name, System.Reflection.Emit.AssemblyBuilderAccess access, string dir, System.Security.Policy.Evidence evidence, System.Security.PermissionSet requiredPermissions, System.Security.PermissionSet optionalPermissions, System.Security.PermissionSet refusedPermissions, ref System.Threading.StackCrawlMark stackMark, System.Collections.Generic.IEnumerable<System.Reflection.Emit.CustomAttributeBuilder> assemblyAttributes, System.Security.SecurityContextSource securityContextSource) + 0x2c bytes
mscorlib.dll!System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName name, System.Reflection.Emit.AssemblyBuilderAccess access) + 0x2b bytes
Castle.Core.dll!Castle.DynamicProxy.ModuleScope.CreateModule(bool signStrongName = true) + 0x1fa bytes
Castle.Core.dll!Castle.DynamicProxy.ModuleScope.ObtainDynamicModuleWithStrongName() + 0x9d bytes
Castle.Core.dll!Castle.DynamicProxy.ModuleScope.ObtainDynamicModule(bool isStrongNamed = true) + 0x2b bytes
Castle.Core.dll!Castle.DynamicProxy.ModuleScope.DefineType(bool inSignedModulePreferably = true, string name = "Castle.Proxies.Invocations.Entity`1_Equals", System.Reflection.TypeAttributes flags = Public | Serializable) + 0x5a bytes
Castle.Core.dll!Castle.DynamicProxy.Generators.Emitters.ClassEmitter.CreateTypeBuilder(Castle.DynamicProxy.ModuleScope modulescope = {Castle.DynamicProxy.ModuleScope}, string name = "Castle.Proxies.Invocations.Entity`1_Equals", System.Type baseType = {Name = "InheritanceInvocation" FullName = "Castle.DynamicProxy.InheritanceInvocation"}, System.Collections.Generic.IEnumerable<System.Type> interfaces = {System.Type[0]}, System.Reflection.TypeAttributes flags = Public | Serializable, bool forceUnsigned = false) + 0x68 bytes
I am using Fluent NHibernate 1.2, NH 3.1 with castle for proxy generation. I am trying to run the application (A simple win-forms app) as a non-admin user and seeing the exception:Unable to obtain public key for StrongNameKeyPair.
Previously (I'm not sure what I did to get around that step), the exception was Creating a proxy instance failed.
Some blog posts from 2010 suggest that Castle's dynamic proxy may have problems with medium trust scenarios, so I've tried my luck with sn -m n
but that doesn't seem to do much.
Is anyone familiar with this behaviour?
Thanks,
JK
Edit:
The application call that generates this exception is a simple LINQ over a NHibernate session.
Here's the top of the stack trace (the whole thing is ~ 60 lines long):
mscorlib.dll!System.Reflection.StrongNameKeyPair.ComputePublicKey() + 0xca bytes
mscorlib.dll!System.Reflection.StrongNameKeyPair.PublicKey.get() + 0x15 bytes
mscorlib.dll!System.Reflection.Emit.AssemblyBuilder.AssemblyBuilder(System.AppDomain domain = {System.AppDomain}, System.Reflection.AssemblyName name = {System.Reflection.AssemblyName}, System.Reflection.Emit.AssemblyBuilderAccess access = Run, string dir = null, System.Security.Policy.Evidence evidence = null, System.Security.PermissionSet requiredPermissions = null, System.Security.PermissionSet optionalPermissions = null, System.Security.PermissionSet refusedPermissions = null, ref System.Threading.StackCrawlMark stackMark = LookForMyCaller, System.Collections.Generic.IEnumerable<System.Reflection.Emit.CustomAttributeBuilder> unsafeAssemblyAttributes = null, System.Security.SecurityContextSource securityContextSource = CurrentAssembly) + 0x4b8 bytes
mscorlib.dll!System.Reflection.Emit.AssemblyBuilder.InternalDefineDynamicAssembly(System.Reflection.AssemblyName name, System.Reflection.Emit.AssemblyBuilderAccess access, string dir, System.Security.Policy.Evidence evidence, System.Security.PermissionSet requiredPermissions, System.Security.PermissionSet optionalPermissions, System.Security.PermissionSet refusedPermissions, ref System.Threading.StackCrawlMark stackMark, System.Collections.Generic.IEnumerable<System.Reflection.Emit.CustomAttributeBuilder> unsafeAssemblyAttributes, System.Security.SecurityContextSource securityContextSource) + 0x7e bytes
mscorlib.dll!System.AppDomain.InternalDefineDynamicAssembly(System.Reflection.AssemblyName name, System.Reflection.Emit.AssemblyBuilderAccess access, string dir, System.Security.Policy.Evidence evidence, System.Security.PermissionSet requiredPermissions, System.Security.PermissionSet optionalPermissions, System.Security.PermissionSet refusedPermissions, ref System.Threading.StackCrawlMark stackMark, System.Collections.Generic.IEnumerable<System.Reflection.Emit.CustomAttributeBuilder> assemblyAttributes, System.Security.SecurityContextSource securityContextSource) + 0x2c bytes
mscorlib.dll!System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName name, System.Reflection.Emit.AssemblyBuilderAccess access) + 0x2b bytes
Castle.Core.dll!Castle.DynamicProxy.ModuleScope.CreateModule(bool signStrongName = true) + 0x1fa bytes
Castle.Core.dll!Castle.DynamicProxy.ModuleScope.ObtainDynamicModuleWithStrongName() + 0x9d bytes
Castle.Core.dll!Castle.DynamicProxy.ModuleScope.ObtainDynamicModule(bool isStrongNamed = true) + 0x2b bytes
Castle.Core.dll!Castle.DynamicProxy.ModuleScope.DefineType(bool inSignedModulePreferably = true, string name = "Castle.Proxies.Invocations.Entity`1_Equals", System.Reflection.TypeAttributes flags = Public | Serializable) + 0x5a bytes
Castle.Core.dll!Castle.DynamicProxy.Generators.Emitters.ClassEmitter.CreateTypeBuilder(Castle.DynamicProxy.ModuleScope modulescope = {Castle.DynamicProxy.ModuleScope}, string name = "Castle.Proxies.Invocations.Entity`1_Equals", System.Type baseType = {Name = "InheritanceInvocation" FullName = "Castle.DynamicProxy.InheritanceInvocation"}, System.Collections.Generic.IEnumerable<System.Type> interfaces = {System.Type[0]}, System.Reflection.TypeAttributes flags = Public | Serializable, bool forceUnsigned = false) + 0x68 bytes
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
非常愚蠢 - 经过一番尝试和错误后,我发现来宾帐户是问题所在。当该帐户位于用户组中时,可以创建一个新帐户。来宾帐户比其他帐户受到更多限制,但我可能认为它可以执行某些它不能执行的操作...
我将保留它,因为我不期望此应用程序有“来宾用户”。
Pretty silly - after a bit of trial and error I found that the Guest account is the problem. Creating a new account, when that account is in the Users group worked. The Guest account is far more restrictive than other accounts, but I probably assumed it can do certain things which it can't...
I'll leave it at that as I'm not expecting a "Guest user" for this application.