Bug 323817 (MONO81133) - mono --security throws System.NullReferenceException
Summary: mono --security throws System.NullReferenceException
Status: RESOLVED FIXED
Alias: MONO81133
Product: Mono: Runtime
Classification: Mono
Component: misc (show other bugs)
Version: 1.2
Hardware: Other Other
: P3 - Medium : Enhancement
Target Milestone: ---
Assignee: Sebastien Pouliot
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords: security
Depends on:
Blocks:
 
Reported: 2007-03-14 03:32 UTC by Michal Okresa
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 20:31:38 UTC


---- Reported by michael@ynet.sk 2007-03-13 20:32:27 MST ----

Description of Problem:
Invocation mono with --security parameter throws always NullReferenceException

Steps to reproduce the problem:
1. for example try to compile this:
http://svn.myrealbox.com/source/trunk/mono/mono/tests/cas/linkdemand/noncas3.cs
2. mono --security CompiledProgram

Actual Results:
[this should print - as JIT will accept the unauthenticated LinkDemand]
*2* Unexpected Exception
System.NullReferenceException: Object reference not set to an instance of
an object
  at System.Security.Policy.PolicyLevel.Resolve
(System.Security.Policy.Evidence evidence) [0x00000]
  at System.Security.SecurityManager.ResolvePolicyLevel
(System.Security.PermissionSet& ps, System.Security.Policy.PolicyLevel pl,
System.Security.Policy.Evidence evidence) [0x00000]
  at System.Security.SecurityManager.ResolvePolicy
(System.Security.Policy.Evidence evidence) [0x00000]
  at System.Security.SecurityManager.ResolvePolicy
(System.Security.Policy.Evidence evidence, System.Security.PermissionSet
reqdPset, System.Security.PermissionSet optPset,
System.Security.PermissionSet denyPset, System.Security.PermissionSet&
denied) [0x00000]
  at System.Reflection.Assembly.Resolve () [0x00000]
  at System.Reflection.Assembly.get_GrantedPermissionSet () [0x00000]
  at System.Security.SecurityManager.IsGranted (System.Reflection.Assembly
a, IPermission perm) [0x00000]
  at System.Security.SecurityManager.CheckPermissionSet
(System.Reflection.Assembly a, System.Security.PermissionSet ps, Boolean
noncas) [0x00000]
  at System.Security.PermissionSet.CheckAssembly
(System.Reflection.Assembly a, SecurityFrame frame) [0x00000]
  at System.Security.PermissionSet.CasOnlyDemand (Int32 skip) [0x00000]
  at System.Security.PermissionSet.Demand () [0x00000]
  at System.Security.SecurityManager.InternalDemand (IntPtr permissions,
Int32 length) [0x00000]
  at System.Threading.Thread.set_CurrentPrincipal (IPrincipal value) [0x00000]
  at LinkDemandTest.Test () [0x00000]
  at LinkDemandTest.Main (System.String[] args) [0x00000]

Expected Results:
[this should print - as JIT will accept the unauthenticated LinkDemand]
*0* [this should print]

How often does this happen? 
always

Additional Information:
In fact I need security manager for real project not for this test. I am
using in .NET PrincipalPermission attribute in this usage:
[PrincipalPermission(SecurityAction.Demand, Role = "test")] as critical
part of remote proxy security.



---- Additional Comments From sebastien@ximian.com 2007-03-13 21:39:16 MST ----

Downgrading priority. Please note that the security manager is
*experimental* (i.e. not supported) and provided only as a preview in
Mono 1.2.

I don't have a x64 to test this myself (it works on my x86) but it
looks like monobuild x64 (sles9) doesn't have this issue using SVN HEAD
http://mono.ximian.com/monobuild/builds/HEAD/sles-9-x86_64/mono/74212/logs/test-cas.log

I'm not sure which version of mono you are using but:

- there was a regression in the stack walking code just before the
last release (but I'm pretty sure it didn't break this test);

- https://bugzilla.novell.com/show_bug.cgi?id=MONO80936 also limited the use of PrincipalPermission (again this
never affect this particular test case).

Both issues will be fixed in the next Mono release but the security
manager is (and stays) experimental and unsupported - i.e. it
shouldn't be used for a "critical part" of anything.

In this particular case, non-CAS permission, the use of imperative
security (source) instead of declarative security (attribute) should
work (in a non-experimental and supported way).



---- Additional Comments From michael@ynet.sk 2007-03-14 09:37:53 MST ----

I have tested latest svn version on AMD Athlon(tm) 64 X2 Dual 
Core Processor 3800+, but 
with ./configure --build=i686-pc-linux-gnu --with-xen_opt. Now it 
works well. It was probably bug in debian's build (mono 1.2.2.1).

Thanks Sebastien, I found useful information about CAS and RBAC in 
your blog. I'll consider to drob declarative security but it will 
have negative impact to current design. 


Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>Debian Etch, kernel 2.6.12.6-xen, x86_64</cf_op_sys_details>
Unknown operating system unknown. Setting to default OS "Other".