SecurityPermission Exception during App Startup when Getting Skins

[GoogleCodeExporter]

I was able to successfully update my staging environment to 2.5.1 and see an 
updated version of the dashboard and my site once, then I touched the 
web.config (no add/remove anything, just modify it so the app would restart) 
and I got a SecurityException. The details are at the end of this email. It 
appears to be a problem whenever the list of skins needs to be enumerated, like 
on the skin configuration page in the admin console.

It seems to be predictable but I'm not sure on what basis. Here's what I can do:

1) Do an IISRESET.
2) Visit the main admin dashboard page (http://sitename/admin/) - that comes up 
fine.
3) Click the "Options" link to visit blog options. That works fine.
4) Click the "Skins" link to configure the skin. This is where I'll get the 
exception.

OR

1) Do an IISRESET.
2) Visit the blog main page (http://sitename/default.aspx) - get the exception.

That second scenario - do the upgrade, run IISRESET, get exception - is the 
most common.

I actually was able to see my blog ONCE with the upgraded site and even click 
through to see the RSS. After that one time, I've gotten the security exception.

There is a discussion thread about this issue here:
http://groups.google.com/group/subtext/browse_thread/thread/95bef9ef6e6df869/966
217645d909bdc

[SecurityException: Request for the permission of type 
'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
   System.Web.Hosting.HostingEnvironment.get_ApplicationHost() +21
   System.Web.Configuration.ServerConfig.get_UseServerConfig() +62
   System.Web.Hosting.MapPathBasedVirtualPathEnumerator..ctor(VirtualPath virtualPath, RequestedEntryType requestedEntryType) +48
   System.Web.Hosting.MapPathBasedVirtualPathCollection.System.Collections.IEnumerable.GetEnumerator() +28
   System.Linq.<OfTypeIterator>d__a3`1.MoveNext() +68
   System.Linq.WhereSelectEnumerableIterator`2.MoveNext() +96
   System.Linq.<SelectManyIterator>d__31`3.MoveNext() +130
   System.Linq.WhereEnumerableIterator`1.MoveNext() +96
   System.Linq.Enumerable.ToDictionary(IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer) +177
   System.Linq.Enumerable.ToDictionary(IEnumerable`1 source, Func`2 keySelector, IEqualityComparer`1 comparer) +102
   Subtext.Framework.UI.Skinning.SkinEngine.GetSkinTemplates(Boolean mobile) +897
   Subtext.Framework.UI.Skinning.ScriptElementCollectionRenderer.get_Templates() +22
   Subtext.Framework.UI.Skinning.ScriptElementCollectionRenderer.RenderScriptElementCollection(String skinKey) +59
   Subtext.Web.UI.Pages.SubtextMasterPage.InitializeBlogPage() +560
   Subtext.Web.UI.Pages.SubtextMasterPage.OnInit(EventArgs e) +28
   System.Web.UI.Control.InitRecursive(Control namingContainer) +333
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +6785
   System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +242
   System.Web.UI.Page.ProcessRequest() +80
   System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +21
   System.Web.UI.Page.ProcessRequest(HttpContext context) +49
   ASP.aspx_dtp_aspx.ProcessRequest(HttpContext context) +4
   Subtext.Infrastructure.PipelineService.ProcessRootRequest(RootRoute route, IRouteHandler routeHandler) +126
   Subtext.Web._Default.Page_Load(Object sender, EventArgs e) +195
   System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +14
   System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +35
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +50
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +6785
   System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +242
   System.Web.UI.Page.ProcessRequest() +80
   System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +21
   System.Web.UI.Page.ProcessRequest(HttpContext context) +49
   ASP.default_aspx.ProcessRequest(HttpContext context) +4
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +181
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75 

Original issue reported on code.google.com by travis.illig on 3 Aug 2010 at 4:33

[GoogleCodeExporter]

Original comment by haac...@gmail.com on 3 Aug 2010 at 4:37

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I am happy to provide a staging environment in Microsoft VPC format to 
developers working on this issue. It is approximately 9GB so you will need a 
place for me to upload it.

Original comment by travis.illig on 3 Aug 2010 at 4:40

[GoogleCodeExporter]

Hey, any chance you could put the site in debug mode and put the pdb files 
there so we can get line numbers? I'm interested in knowing which line    

Subtext.Framework.UI.Skinning.SkinEngine.GetSkinTemplates(Boolean mobile) +897 

is failing on

Original comment by haac...@gmail.com on 3 Aug 2010 at 4:41

[GoogleCodeExporter]

I would be happy to if you give me the symbols to put in place. They are not 
included in the downloadable zip package.

Original comment by travis.illig on 3 Aug 2010 at 4:44

[GoogleCodeExporter]

I took a deeper look at the stack trace and found a couple problems. The good 
news is this shouldn't happen in ASP.NET 4. ;)

The other weird thing is it appears that your code is falling into the 
non-medium trust case. In SkinEngine.cs we have a case statement. The code that 
appears to be executing is in the following case:

    case AspNetHostingPermissionLevel.Unrestricted:
    case AspNetHostingPermissionLevel.High:

However, if you're running in Medium trust, you should be falling through to 
the default: case, which goes directly to the filesystem.

I have a copy of your VM so I'll try to instrument it and see what's going on 
under the hood.

Original comment by haac...@gmail.com on 3 Aug 2010 at 5:10

[GoogleCodeExporter]

I think you're right in where it's failing, but it's failing on getting 
SecurityPermission, not AspNetHostingPermission, so maybe there's more than 
just AspNetHostingPermission required to do what is being done? (Or maybe it 
really is AspNetHostingPermission failing and the error message is misleading. 
Code access security is such a pain.)

Original comment by travis.illig on 3 Aug 2010 at 6:35

[GoogleCodeExporter]

It's failing on a call to the getter for HostingEnvironment.ApplicationHost 
which has a Security demand for full trust. In .NET 4, this code path wouldn't 
call this property.

However, if you're running in a true medium trust, you shouldn't even be going 
through the code path that leads to this call in the first place. That's why I 
think something is borked about your medium trust settings.

Original comment by haac...@gmail.com on 3 Aug 2010 at 8:14

[GoogleCodeExporter]

My medium trust setup could very well be messed up; hopefully you can see what 
it is.

On a larger note, even in .NET 4, I'm betting that hosts don't always run with 
exactly the out-of-the-box Medium trust. I know my host is just a tiny more 
permissive in certain areas. I wonder if a better practice for future 
permission checks/asserts is to check for all of the required permissions 
rather than just assuming that if we're set in "medium trust" then it implies 
other permissions are available. I'm sure my environment would have failed 
those checks and fallen through.

No finger pointing or anything, just something to consider.

(Of course, it's a different permission model altogether in .NET 4 so maybe it 
all becomes moot.)

Original comment by travis.illig on 3 Aug 2010 at 8:21

[GoogleCodeExporter]

Created a patch for this issue against the Release2.5 branch so it can be 
integrated into an updated build post 2.5.1.20. I will hold off on updating my 
production environment until a new release is posted so I can test the new 
release in my staging environment.

The root of this issue is that VirtualPathProvider requires more than just 
AspNetHostingPermission to function but the test used to determine if VPP 
should be used relied solely on AspNetHostingPermission.

It was slightly complicated in that the actual calls using the VPP were inside 
LINQ statements which don't actually execute until the IEnumerator actually 
gets enumerated (in this case, via a ToDictionary() call).

The patch addresses this by using a try/catch(SecurityException) wrapper around 
the entire usage of VPP in the skin engine rather than trying to "sniff" the 
trust level using only AspNetHostingPermission.

Original comment by travis.illig on 18 Oct 2010 at 4:15

Attachments:

• issue-252.patch

[GoogleCodeExporter]

Original comment by haac...@gmail.com on 1 Nov 2010 at 4:05

• Added labels: Milestone-Release2.5.1

[GoogleCodeExporter]

Fixed in r4136

Original comment by haac...@gmail.com on 1 Nov 2010 at 4:20

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by haac...@gmail.com on 1 Nov 2010 at 6:11

• Added labels: Milestone-Release2.5.2
• Removed labels: Milestone-Release2.5.1