[Mono-bugs] [Bug 62358][Nor] Changed - MCS doesn't encode SecurityAttributes properly

[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 sebastien@ximian.com.

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

--- shadow/62358	2004-09-16 11:39:55.000000000 -0400
+++ shadow/62358.tmp.18744	2004-10-05 10:49:58.000000000 -0400
@@ -231,6 +231,41 @@
 Informational Note (this shouldn't affect the compiler):
 
 The 2.0 runtime doesn't encode security permission as XML. They are
 encoded just like other "normal" permissions (space saver). However
 they are still located in the same place - and can't be read by
 GetCustomAttribute(s).
+
+------- Additional Comments From sebastien@ximian.com  2004-10-05 10:49 -------
+There are also three "hidden" security actions (with different IDs)
+that deals with non-CAS permissions. I.e. permissions that do not
+derive from CodeAccessPermission - but still implements IPermission
+(e.g. PrincipalPermission).
+
+from /mono/mono/metadata/tabledefs.h (recent CVS)
+SECURITY_ACTION_NONCASDEMAND        = 13,
+SECURITY_ACTION_NONCASLINKDEMAND    = 14,
+SECURITY_ACTION_NONCASINHERITANCE   = 15,
+
+This requires the compiler to split entries for Demand, LinkDemand and
+InheritDemand based on the type of the permission. 
+
+* see attached: casnoncas.cs
+  compile with CSC and disassemble with ILDASM (or CVS monodis)
+
+Calling .AddDeclarativeSecurity, with the appropriate (visible or
+hidden) SecurityAction should encode permissions correctly in the
+metadata.
+
+
+Note 1: It seems that adding only a non-CAS permission also creates an
+(empty) CAS permission set. I don't know if this is important (i.e.
+required on MS runtime ?) because it has no value (empty) and takes
+more processing (adds an unrequired call from unmanaged to managed).
+
+* see attached: noncasonly.cs
+  compile with CSC and disassemble with ILDASM (or CVS monodis)
+
+
+Note 2: the "hidden" actions doesn't seems to be used in the new
+metadata format used by 2.0.
+