Jaa

Feedback on Link and Disjunctive Demands

  • Artikkeli

In the spirit of gathering feedback from the community, here are two more feature areas we're interested in knowing how you use:

  • Have you ever encountered the need to use a LinkDemand for a permission that did not inherit from CodeAccessPermission.  (For instance a custom, non-CAS permission, or one of the Principal permissions)?
  • In the beta 1 release of Whidbey, we introduced a new feature called disjunctive security, which basically allows you to have multiple declarative demands on a single method that were logically or'ed together.  The major reason for introducing this feature to solve the common scenario where a method needed to be protected with a LinkDemand that would prevent anyone who wasn't signed with one of a specific set of public keys from calling into it.  Whidbey also introduced friend assemblies, which can help you achieve the same goal.  Are there other scenarios that you are using or are planning to use disjunctive security to solve, which cannot be achieved through the use of friend assemblies or other features?

Comments

  • Anonymous
    February 16, 2005
    a) Yes I've already implemented something like that using a custom (non CAS) IPermission based class. LinkDemand was cheaper to use (but a full Demand would have worked).

    b) The only time I missed that feature (1.0/1.1) was for grouping multiple identity permissions together. We prefered using declarative security (as much as possible) to allow "easier reviewing" of the permissions. However I much prefer using declarations at a class/method level than at the assembly level.
  • Anonymous
    February 16, 2005
    a) So far, only in scenarios for which DemandChoice would be a better option. That said, I do have a plan to use a custom non-CAS permission that would be quite expensive to verify under certain conditions. Having the option to use a LinkDemand where appropriate could help avoid some performance bottlenecks.

    b) There are scenarios where I would find DemandChoice to be very useful. For example, when invoking a managed wrapper that calls into an unmanaged API (e.g.: OpenFileDialog), the managed wrapper often maps from some other permission onto UnmanagedCode permission. In this sort of situation, I might want to be able to use DemandChoice to force all calling code to have either UnmanagedCode permission or the permission demanded by the managed wrapper. (In the OpenFileDialog example, this might mean asserting FileDialogPermission after making a disjunctive demand for FileDialogPermission or UnmanagedCode permission.)
  • Anonymous
    February 26, 2005
    "Whidbey also introduced friend assemblies, which can help you achieve the same goal."

    I have a real issue with recommending friend assemblies to achieve the same goal:
    1. This couples assemblies. You have to specify the assembly name for the InternalsVisibleToAttribute, but what you more likely want to do is specify which "strong name callers" can access all of your types. With StrongNameIdentityPermissionAttribute I can (yes, for each type) specify a group of callers by their private key signature - i.e., approved partners or more likely "our" assemblies).

    2. InternalsVisibleTo does not prevent reflection over types and members, even if those types/members are internal/protected/private. StrongNameIdentityPermissionAttribute does protect private members (et. al.) if you apply it at the type level (it can't be applied to fields).

    IMHO on very rare occasions should friend assemblies be leveraged.
    Thankfully, now we have DemandChoice to specify multiple valid strong name demands/linkdemands.
  • Anonymous
    March 08, 2005
    Oops... I missed the friend assemblies aspect of this that Michele caught. I've already responded to a similar recommendation to use friend assemblies in place of identity permissions at http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=e6d03969-e4f1-4b81-a051-2540429efee2. In case you don't want to wade through that mess, my two main points from there are:

    1. One might want to expose a semi-public API to assemblies that don't yet exist at the time the API is released.

    2. Not all internally visible types and members should necessarily form part of a semi-public API.

    I also agree with Michele's point concerning reflection, but it'll become largely irrelevant if fully trusted code passes all identity permissions since most code that has permission to reflect into internally visible members acquires that permission via a full trust grant.