Where did my permission set controls go?

  • Makale

I’m going to diverge a bit off the VSTO path and talk about a more generic ClickOnce story.  If you have used ClickOnce in VS 2008 or VS 2005 you may be somewhat familiar with partial trust scenarios and the idea of permission sets.  If you do not care about partial trust but instead live in the world of using full-trust (such as VSTO requires) then you can skip this post as it may be irrelevant to you. 

The Setup

If you haven’t heard yet, we are in the midst of shipping the Beta for VS 2010.  You can read more about it here: 

https://blogs.msdn.com/somasegar/archive/2009/05/18/visual-studio-2010-and-net-fx-4-beta-1-ships.aspx

There are many exciting new features and changes occurring in this cycle.  As a product of some of these changes I’ve been seeing a lot of questions about some of the changes being made.  I’d like to answer at least one of them now.

The Question

“I went to customize my zone permissions and noticed that the control that lists the zone permissions is missing!  Is this a bug or is this control moved somewhere else?  I need to know how to customized the internet zone so my application will work.  How do I do this in VS 2010?”

Here is a screenshot of said control in VS 2008 (on Vista):

PermissionPage

Here is a screenshot from VS2010 Beta 1 (on Server 2008):

Permissions2010

The Short Answer

This is not a bug, we intentionally removed this control within VS 2010. 

The Long Answer

So the question itself is just one of the reasons that this control was removed.  As it turns out there is an implied functionality/design in this control that confuses developers about how the security model works.  Conceptually it is easy to look at this control and assume that you can set a “zone” and then customize the permissions that should work within that zone.  But this is not the case and this is where the confusion comes into play.

What this control essentially does is create a Custom Permission Set and compare it to the permission set of a “well known” zone.  If you change the setting element to anything other than Zone Default, you’ve defined a “custom” permission set and that is what your application will request.  In VS 2008 and VS 2010, this same functionality can be achieved by adding the individual permissions to the <TrustInfo> element in the app.manifest file.  In VS 2010, this will be the only way to define a “custom” permission set.  You can find an older MSDN article on how to do this here: https://msdn.microsoft.com/en-us/library/6ad1fshk(VS.80).aspx.

Our belief is that most customers that use this control are under the impression they get some benefit from using the custom sets, but in most cases they are not getting the benefit they believe they are getting.  The misconception comes about because the impact of changing things in this control are non-obvious.  So let’s break this down into 3 scenarios and describe what happens, why, and alternatives that get the same effect.

Target Internet Zone: Do not change anything.

If your application really does need only the internet permission set, it will work without a trust prompt as long as you run it from the following zones:  Internet, Local Intranet, My Computer.  You do not see a trust prompt (assuming your application is signed with a “known” certificate that chains to a Trusted Root Authority) because you have provided “evidence” (the permissions you requested,where it is run from, and a “known” certificate signature) saying your application will only execute within the confines of the functionality allowed for applications that execute within that zone.  If your application needs any permissions outside of this zone, it will fail with a “trust/security” error.

In VS 2010, we support this scenario with the current UI, the “Zone your application will be install from:” control is what determines the permissions set. 

Target Internet Zone: Remove a Permission.

You are no longer targeting the “Internet” Permission set but rather a custom set.  If your application is published on the internet, local intranet, or my computer zones, it will function without a trust prompt exactly like targeting the internet zone.  There is a caveat here, but I will come back to it (See Caveat:  Least Permissions).

In VS2010, there are 2 options to achieve this:  You could have simply targeted the internet zone or you can define the custom set your application needs in the app.manifest file manually.  Our general recommendation is to target the well-known-zone that your application runs from rather than defining custom permission sets.

Target Internet Zone: Add a Permission.

In this scenario, your customers will get the ClickOnce trust prompt.  We believe users of the permission set control fall into this bucket.  The reality of the security model is that at this point once you have incurred a trust prompt of any kind you might as well be targeting “full trust” since your end user will not see a difference.

In VS2010, if you cannot run under the permission set of the zone you are targeting, we recommend that you switch your application to requesting full trust.  Functionally to the end user, this is exactly the same as if you had targeted a custom set that exceeds the permissions of the zone your application is installed or run from.  You can manually configure the custom set using the app.manifest xml file within the project.

Caveat: Least Permissions

Our team is aware there is a segment of our developer customers that prefers to target the “least” number of permissions required in which to run their application.  While we do understand this UI made it much easier to do this, we believe that this segment is familiar enough with permission sets that they are capable of achieving the appropriate settings using the app.manifest xml file.  Please continue reading if you would like to understand the other justifications for why this UI was removed.

How we came to this final decision (or rather “other aspects involved”):

Generally we don’t remove UI or features without good reasons.  In this case, we discussed at length with the Security Team about this specific piece of UI.  They have indicated to us that they believe the general focus of their customers should be to move away from “custom” permission sets and more to targeting only the well-known permission sets or fully trust.

Beyond the general “this is the direction we want to take this feature,” VS 2010 includes some changes that made removing this UI desirable from a technical perspective.  If you have not noticed yet, VS 2010 allows you to target/build and debug solutions against both CLR 2.0 (.NET version 2.0, 3.0 and 3.5) and CLR 4.0 (.NET version 4.0).  Visual Studio itself runs against CLR 4.0.  In previous cycles, the assumption was that VS would only run against the CLR version it targets, but that assumption is no longer true.  As a result, many elements of VS have had to change because VS cannot always rely on the CLR it is running against to provide the correct information for the project (if it targets a different CLR).  Our permission set control falls under the bucket of things that functioned on this basic assumption.  When we looked at what the cost of changing the design was and how it would impact the overall user story, we determined that it was better for our customers that we removed the UI and focused on improving the other aspects of the product.  We feel that the loss of improved functionality (how easy it is to setup custom permissions) did not outweigh the gains we could apply elsewhere.

Thank You for reading.

Kris

Comments