[Mono-devel-list] Compatibility/testing issues with security permissions

[Miguel de Icaza]

Hey,

> The major problem are:
> 
>         * "Over protection" for some resources (this isn't a security
>         problem but may impact performance);
>         
>                 E.g. Microsoft's System.Reflection.StrongNameKeyPair
>                 implementation requires UnmanagedCode permission (maybe
>                 because it call an unmanaged API, maybe not...).
>                 
>                 Mono's implementation of StrongNameKeyPair is completely
>                 managed and the class, by itself, doesn't do much. So we
>                 could possibly (if the code using the class is properly
>                 protected!) skip the check.

This is something that we encountered elsewhere: basically our
implementation would allow more things than the Microsoft runtime would
allow, and might give people a false sense of portability.

But this in particular seems to impact only a very small subset of users
(definitely none of those are using Mono today) that I think we might
want to do this as a `value add' of our implementation: remove the
check, as we do not have the unmanaged code requirement.
 
>         * "Over protection" can also be misleading as sometimes a
>         permission is used because of it's end effect - not it's true
>         meaning. A common pattern is to require UnmanagedCode because
>         you only want highly trusted code to execute (yes there are
>         better ways to do it).
>                 
>                 E.g. Environment.MachineName requires UnmanagedCode
>                 permission, while other similar properties (e.g.
>                 UserDomainName, UserName, ...) doesn't. 
>                 
>                 The UnmanagedCode requirement is documented (in this
>                 case) but it doesn't tell why it is required!

This might be also a Microsoft limitation;  The question really is
whether we introduce a potential hole, and my feeling is not.

> However I really don't want to mix (source wise) the security test cases
> with the current unit test case. This is mostly to allow easier tracking
> and reviews in the future. So I propose that the new source tests files
> ends with Cas.cs (or CasTest.cs if something depends on tests ending
> with *Test.cs).
> 
> E.g.	EnvironmentCas.cs	or
> 	EnvironmentCasTest.cs

I agree, this sounds better.

miguel