StrongNameIdentityPermission not checked

[James Hadwen]

I'm not sure whether I'm doing something wrong, or
StrongNameIdentityPermission just doesn't work in 2.0 beta 2 yet.

public class Class1
{
[StrongNameIdentityPermission(SecurityAction.Demand , PublicKey =
Keys.PUBLIC_KEY)]
public Class1()
{
System.Diagnostics.Debug.Assert(Assembly.GetCallin gAssembly().GetName().GetPublicKey().Length
!= 0);
}
}

Obviously the Assert shouldn't evaluate to true, and it doesn't when
compiled to 1.1. However it's clear that the StrongNameIdentityPermission is
being ignored in 2.0 as the assert indeed can evaluate to true.

Is there something different that I've neglected, or has security in the CLR
not been implemented yet?

Thanks in advance

James

[Nicole Calinoiu]

I was able to reproduce the problem using the December CTP. It looks like a
few changes have been made to StrongNameIdentityPermission, and the problem
seems to lie there rather than in the attribute class. Have you reported
this as a bug?

BTW, there are VStudio 2005-specific newsgroups available at
http://lab.msdn.microsoft.com/vs2005...s/default.aspx
(incl. NNTP connection settings documentation). These would be a better
place for questions pertaining the beta, particularly since they seem to be
monitored by relevant MS staff.

"James Hadwen" <ms*************@7internet.co.uk> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I'm not sure whether I'm doing something wrong, or
StrongNameIdentityPermission just doesn't work in 2.0 beta 2 yet.

public class Class1
{
[StrongNameIdentityPermission(SecurityAction.Demand , PublicKey =
Keys.PUBLIC_KEY)]
public Class1()
{

System.Diagnostics.Debug.Assert(Assembly.GetCallin gAssembly().GetName().GetPublicKey().Length
!= 0);
}
}

Obviously the Assert shouldn't evaluate to true, and it doesn't when
compiled to 1.1. However it's clear that the StrongNameIdentityPermission
is being ignored in 2.0 as the assert indeed can evaluate to true.

Is there something different that I've neglected, or has security in the
CLR not been implemented yet?

Thanks in advance

James

[Nicole Calinoiu]

Turns out it might be by design. Looks like the intent might be to allow
fully trusted callers to pass demands for all identity permissions (see the
third paragraph of the 2004-09-17 MS comment at
http://lab.msdn.microsoft.com/produc...-48a4d0c8e6b1).
That said, in my tests, the demand passes even if the "unnamed" caller is
only partially trusted, so the current implementation would seem to be buggy
regardless...

"James Hadwen" <ms*************@7internet.co.uk> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I'm not sure whether I'm doing something wrong, or
StrongNameIdentityPermission just doesn't work in 2.0 beta 2 yet.

public class Class1
{
[StrongNameIdentityPermission(SecurityAction.Demand , PublicKey =
Keys.PUBLIC_KEY)]
public Class1()
{

System.Diagnostics.Debug.Assert(Assembly.GetCallin gAssembly().GetName().GetPublicKey().Length
!= 0);
}
}

Obviously the Assert shouldn't evaluate to true, and it doesn't when
compiled to 1.1. However it's clear that the StrongNameIdentityPermission
is being ignored in 2.0 as the assert indeed can evaluate to true.

Is there something different that I've neglected, or has security in the
CLR not been implemented yet?

Thanks in advance

James