locked
InitializeLifetimeService override security error with previously working code. RRS feed

  • Question

  • I have a remotable object derived from MarshalByRefObject that has the usual InitializeLifetimeService override to return null, the usual SecurityPermissionAttribute on it, and which has been working since .NET 2.0 at least.  After upgrading to Beta 2, I get the following message on starting the application: "Inheritance security rules violated while overriding member:'InitializeLifetimeService()'. Security accessibility of the overriding member must match the security accessibility of the method being overridden."

    What do I need to do to fix this?

    Friday, October 30, 2009 10:37 PM

Answers

  • Glad that you were able to solve your problem Stan.   I'd be glad to provide some of the details of why removing APTCA solves this problem.

    In .NET 4, we've moved to using the security transparency model as a first class security enforcement mechanism of the platform.   One of the rules of the new security transparency system is that all overriden virtuals must have the same security accessibility as their original virtual declaration.  In this case, since InitializeLifetimeService is security critical, the security rule requires that all overriden virtuals also be security critical.

    As part of the new security transparency model, the AllowPartiallyTrustedCallersAttribute has a slightly different meaning.  It now means that all code in your assembly is security transparent by default, unless otherwise specified.  (Semantically this means the same as it always used to - however at the nuts and bolts level, it is now implemented in terms of transparency).

    Therefore, your APTCA attribute was saying that your InitializeLifetimeService method was security transpraent, but the transprency rules were requiring it to be security critical instead.  That resulted in the exception that you were seeing.  By removing APTCA, you made the assembly agnostic to transaprency, and the CLR took care of ensuring that it was automatically correct from a transpraency perspective.

    Alternative ways you could have also solved this particular problem include:
    * Marking your InitializeLifetimeServices method with the SecurityCritical attribute.  This may have some additional fanout, since callers of this method must also now be marked security critical.   We will be offering tools to make going down this route easier, although they unfortunately did not ship in the Beta 2 package.

    * Add the [assembly: SecurityRules(SecurityRuleSet.Level1)] attribute - this locks your assembly back to the v2.0 transparency model, where the APTCA attribute was implemented in terms of link demands rather than the new transparency model.  This route should generally be used for migration purposes - so that your assembly continues to work while you cut it over to the v4 security model.

    However, it sounds like removing APTCA was a good enough solution for you - and that's definately a great way to solve this issue, so keeping that modification in place seems to me like a very reasonable way to go.

    -Shawn Farkas [MS]
    http://blogs.msdn.com/shawnfa
    Monday, November 2, 2009 6:26 PM

All replies

  • Well, digging in a bit more, I found that the error can be solved by removing the [AllowPartiallyTrustedCallers] attributes from my library assembly and its client.  The attribute was required in earlier versions of the framework to allow remote clients to call into it.  That appears to no longer be the case because I can run and connect remotely after removing all of the [AllowPartiallyTrustedCallers] attributes!

    Can anybody make this warm and fuzzy by providing an explanation for the change in behavior?

    Thanks,
    Stan
    Friday, October 30, 2009 10:57 PM
  • Glad that you were able to solve your problem Stan.   I'd be glad to provide some of the details of why removing APTCA solves this problem.

    In .NET 4, we've moved to using the security transparency model as a first class security enforcement mechanism of the platform.   One of the rules of the new security transparency system is that all overriden virtuals must have the same security accessibility as their original virtual declaration.  In this case, since InitializeLifetimeService is security critical, the security rule requires that all overriden virtuals also be security critical.

    As part of the new security transparency model, the AllowPartiallyTrustedCallersAttribute has a slightly different meaning.  It now means that all code in your assembly is security transparent by default, unless otherwise specified.  (Semantically this means the same as it always used to - however at the nuts and bolts level, it is now implemented in terms of transparency).

    Therefore, your APTCA attribute was saying that your InitializeLifetimeService method was security transpraent, but the transprency rules were requiring it to be security critical instead.  That resulted in the exception that you were seeing.  By removing APTCA, you made the assembly agnostic to transaprency, and the CLR took care of ensuring that it was automatically correct from a transpraency perspective.

    Alternative ways you could have also solved this particular problem include:
    * Marking your InitializeLifetimeServices method with the SecurityCritical attribute.  This may have some additional fanout, since callers of this method must also now be marked security critical.   We will be offering tools to make going down this route easier, although they unfortunately did not ship in the Beta 2 package.

    * Add the [assembly: SecurityRules(SecurityRuleSet.Level1)] attribute - this locks your assembly back to the v2.0 transparency model, where the APTCA attribute was implemented in terms of link demands rather than the new transparency model.  This route should generally be used for migration purposes - so that your assembly continues to work while you cut it over to the v4 security model.

    However, it sounds like removing APTCA was a good enough solution for you - and that's definately a great way to solve this issue, so keeping that modification in place seems to me like a very reasonable way to go.

    -Shawn Farkas [MS]
    http://blogs.msdn.com/shawnfa
    Monday, November 2, 2009 6:26 PM

  • We will be offering tools to make going down this route easier, although they unfortunately did not ship in the Beta 2 package.

    Any chance for clarification on these tools? Did they ship with RTM, and if so where and what are they called?
    Tuesday, April 20, 2010 1:55 AM