[Mono-bugs] [Bug 52693][Wis] New - Unsupported declarative permissions

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by spouliot@videotron.ca.

http://bugzilla.ximian.com/show_bug.cgi?id=52693

--- shadow/52693	2004-01-08 20:27:07.000000000 -0500
+++ shadow/52693.tmp.31430	2004-01-08 20:27:07.000000000 -0500
@@ -0,0 +1,134 @@
+Bug#: 52693
+Product: Mono/Runtime
+Version: unspecified
+OS: All
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: spouliot@videotron.ca               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Unsupported declarative permissions
+
+NOTE: This isn't "really" CAS (Code Access Security) related! See bugzilla
+#52606 for CAS runtime implementation.
+
+
+Description of Problem:
+
+Declarative PrincipalPermission are often used in multi-tiered applications
+to implement RBAC (Role Based Access Control). Without runtime support for
+declarative permissions the software will work but won't respect any role
+based checks (at least the declarative ones) - which is really bad.
+
+
+Steps to reproduce the problem:
+1. Compile and run the attached sample
+
+Actual Results (using Mono 0.29 on Windows):
+
+Declarative (me)
+I'm a mono hacker :)
+Declarative (you)
+You're a mono hacker :(
+Imperative (me)
+
+Unhandled Exception: System.NullReferenceException: A null value was found
+where
+ an object instance was required
+in <0x0000b> System.Security.SecurityException:ToString ()
+in <0x0017d> .PrincipalTest:Main (string[])
+
+
+Note:	*** The NullReferenceException bug in SecurityException has been
+fixed in CVS (bugzilla #52626) ***
+
+
+Expected Results (using MS runtime on Windows):
+
+Declarative (me)
+I'm a mono hacker :)
+Declarative (you)
+System.Security.SecurityException: Request for principal permission failed.
+   at System.Security.Permissions.PrincipalPermission.Demand()
+   at System.Security.PermissionSet.Demand()
+   at PrincipalTest.DeclarativeYou() in c:\documents and
+settings\spouliot\my do
+cuments\visual studio projects\mono\samples\principal\principal.cs:line 63
+   at PrincipalTest.Main(String[] args) in c:\documents and
+settings\spouliot\my
+ documents\visual studio projects\mono\samples\principal\principal.cs:line 25
+Imperative (me)
+I'm a mono hacker :)
+Imperative (you)
+System.Security.SecurityException: Request for principal permission failed.
+   at System.Security.Permissions.PrincipalPermission.Demand()
+   at PrincipalTest.Imperative(String user) in c:\documents and
+settings\spoulio
+t\my documents\visual studio
+projects\mono\samples\principal\principal.cs:line 5
+0
+   at PrincipalTest.Main(String[] args) in c:\documents and
+settings\spouliot\my
+ documents\visual studio projects\mono\samples\principal\principal.cs:line 41
+
+
+How often does this happen? 
+Always
+
+
+Additional Information:
+
+It may look like, but's it isn't, CAS (Code Access Security) related.
+PrincipalPermission doesn't requires any stack walk to evaluate - in fact
+the evaluation code must exist inside the IPrincipal class (which is very
+different from IStackWalk classes).
+
+PrincipalPermission
+- implements IPermission (Copy/Demand/Intersect/IsSubsetOf/Union)
+- doesn't inherit from CodeAccessPermission - e.g. it implements its own
+Demand method
+- doesn't implements IStackWalk (so no Assert/Deny/PermitOnly)
+
+PrincipalPermissionAttribute
+- inherit from CodeAccessPermissionAttribute, not because it's CAS related,
+but it does so the runtime can call it's IPermission.CreatePermission() to
+execute the required SecurityDemand. 
+
+The "nice" things about implementing this into the runtime (before CAS) are: 
+- no stack walks are necessary to implement PrincipalPermission;
+- the runtime modifications (to intercept CodeAccessPermissionAttribute and
+call the permissions objects) will be resuable later to implement CAS.
+- this should works for other non-CAS permissions (like custom
+PrincipalPermission-like classes which Motus uses).
+
+My knowledge of Mono's runtime is _very_ limited but here's a C#-like of
+what should be done before branching into a method:
+
+foreach (Attribute a in method_attrs) {
+	CodeAccessSecurityAttribute cas = (a as CodeAccessSecurityAttribute);
+	if (cas != null) {
+		IPermission p = cas.CreatePermission ();
+		if (p == null)
+			throw new SecurityException ("null permission - this should not happen",
+cas.GetType ());
+		switch (p.Action) {
+			case SecurityAction.Demand:
+				p.Demand ();
+				break;
+			default:
+				// other security actions are currently unsupported by mono
+				break;
+		}
+	}
+}
+
+This shouldn't affect the "real" CAS permissions inside assemblies because
+CodeAccessPermission.Demand() is (currently) empty (so it won't throw a
+SecurityException or a NotImplementedException).