Trust issue

Sep 6, 2011 at 5:25 AM

Had 2.0.  Just went to 2.5.0.11 and get this error:

 

Server Error in '/' Application.

Security Exception

Description: The application attempted to perform an operation not allowed by the security policy.  To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.


Stack Trace:

[SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
   System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) +0
   System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark) +31
   System.Security.CodeAccessPermission.Demand() +46
   System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath) +597
   System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) +83
   System.Configuration.Internal.InternalConfigHost.StaticOpenStreamForRead(String streamName) +79
   System.Configuration.Internal.InternalConfigHost.System.Configuration.Internal.IInternalConfigHost.OpenStreamForRead(String streamName, Boolean assertPermissions) +124
   System.Configuration.Internal.InternalConfigHost.System.Configuration.Internal.IInternalConfigHost.OpenStreamForRead(String streamName) +10
   System.Configuration.Internal.DelegatingConfigHost.OpenStreamForRead(String streamName) +13
   System.Configuration.UpdateConfigHost.OpenStreamForRead(String streamName) +38
   System.Configuration.BaseConfigurationRecord.InitConfigFromFile() +450



Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.1

Coordinator
Sep 6, 2011 at 7:49 PM
Edited Sep 6, 2011 at 7:53 PM

You need write permission on app_data folder and trust level set to "high" or "full" in IIS (or admin console for web hosting). When upgrading, file permissions can get overwritten and might need a reset.

Recently I've seen this error with 2.5.0.11 and had to add full trust directive to the web.config - even though IIS told me it is already full trust. Not sure why, but it fixed it.

Sep 7, 2011 at 12:42 PM

That is not good... to require full or high trust knocks out the vast majority of shared host (including mine). 

What is requiring full trust in 2.5?  Is there a way to make it dynamic in nature for the different setups?

Sep 7, 2011 at 11:40 PM
Edited Sep 7, 2011 at 11:41 PM
rtur wrote:

You need write permission on app_data folder and trust level set to "high" or "full" in IIS (or admin console for web hosting). When upgrading, file permissions can get overwritten and might need a reset.

Recently I've seen this error with 2.5.0.11 and had to add full trust directive to the web.config - even though IIS told me it is already full trust. Not sure why, but it fixed it.

Hi rtur, I have just upgraded from 2.5.0.5 to 2.5.0.11 and also ran into this issue - hosting on go daddy. This post of yours helped me fix the problem.
My App_Data folder already had write permissions granted but I needed to add full trust to the web.config to get things working.
For anyone who's interested and wants to know how to do that (I'd not had to set trust before, look for your system.web and amend it like this:

<system.web>
	<securityPolicy>
     <trustLevel name="Full" policyFile="internal" />
	 </securityPolicy>
	 <trust 
      level="Full" 
      originUrl="" 
      processRequestInApplicationTrust="true" 
   />
    <compilation debug="true" targetFramework="4.0">

 

There might be a better way, and if anyone knows then please follow up as I'm uncomfortable with needing to enable full trust.
I don't really know much about it, but every time I've seen anyone talk about it and hosting it's been to say that it isn't a good thing.

Curious to know what's changed since 2.5.0.5 that requires full trust though

Sep 8, 2011 at 8:07 AM

This is just a non-starter for my host (and many others, actually shocked GoDaddy is allowing this).

 

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: This configuration section cannot be used at this path.  This happens when the site administrator has locked access to this section using <location allowOverride="false"> from an inherited configuration file.

Sep 8, 2011 at 8:23 AM

Still looking into this, don't know enough about this code to give an answer yet.. but here is the more detailed error:

An error occurred loading a configuration file: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed. (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config)
   at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
   at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
   at System.Configuration.Configuration..ctor(String locationSubPath, Type typeConfigHost, Object[] hostInitConfigurationParams)
   at System.Configuration.Internal.InternalConfigConfigurationFactory.System.Configuration.Internal.IInternalConfigConfigurationFactory.Create(Type typeConfigHost, Object[] hostInitConfigurationParams)
   at System.Web.Configuration.WebConfigurationHost.OpenConfiguration(WebLevel webLevel, ConfigurationFileMap fileMap, VirtualPath path, String site, String locationSubPath, String server, String userName, String password, IntPtr tokenHandle)
   at BlogEngine.Core.Providers.BlogService.LoadProviders() in C:\ck\Personal Web Sites\DNBE2.5.0.11\DotNetSlave.BusinessLogic\Providers\BlogService.cs:line 876
   at BlogEngine.Core.Blog.get_Blogs() in C:\ck\Personal Web Sites\DNBE2.5.0.11\DotNetSlave.BusinessLogic\Blog.cs:line 378
   at BlogEngine.Core.Blog.get_CurrentInstance() in C:\ck\Personal Web Sites\DNBE2.5.0.11\DotNetSlave.BusinessLogic\Blog.cs:line 456
   at BlogEngine.Core.Right.EnsureBlogInstanceDataLoaded() in C:\ck\Personal Web Sites\DNBE2.5.0.11\DotNetSlave.BusinessLogic\Security\Right.cs:line 542
   at BlogEngine.Core.Right..cctor() in C:\ck\Personal Web Sites\DNBE2.5.0.11\DotNetSlave.BusinessLogic\Security\Right.cs:line 113

Sep 8, 2011 at 8:28 AM

Totally guessing here, curious if I am right...

Looks like the multiple blog support is the culprit.  It appears that the code creates new virtual directories on the fly for each blog instance?


This, obviously, won't be allowed on most shared host...

Sep 8, 2011 at 8:32 AM
ckincincy wrote:

Looks like the multiple blog support is the culprit.  It appears that the code creates new virtual directories on the fly for each blog instance?

If this is the case there needs to be a means to disable it.
I know the multiple blog support is a requested feature but I'm not using it, pretty sure most people wont be using it yet either and this full trust issue might well prevent many from taking the upgrade.

Coordinator
Sep 8, 2011 at 4:16 PM

If that is the case, we definitely need to make this feature optional.

Although I have to point out that BE *always" required "high" or custom trust level for many features like HTTP requests outside domain, remote file download, reflection etc. Fortunately, most hosts allow it.

Sep 8, 2011 at 4:28 PM

Although I have to point out that BE *always" required "high" or custom trust level for many features

It has not required "high."  It may be custom, but it isn't anywhere near "high."

Coordinator
Sep 8, 2011 at 5:39 PM

If it doesn't run on medium, it requires high or custom, isn't it? In early versions it was implicitly set to high in web.config, that was removed later as some hosts would not allow override trust in web.config.

Sep 8, 2011 at 5:49 PM

I'm just telling you that on several shared hosting providers I have been able to host DNBE without issue on a security level that is not near high.  So I get that custom is likely there, but don't think its high.  Will do some more testing tonight on this.

Sep 9, 2011 at 1:26 AM

Version 2.0 and below works fine on Medium trust.  Strait, vanilla medium trust. 

Coordinator
Sep 9, 2011 at 4:42 AM
Edited Sep 9, 2011 at 4:43 AM

Yes, it loads fine, although it throws errors trying to call blogroll code. Check out your blogroll widget - it is empty because those calls failed.

It also won't let you use windows live writer, akismet and more - anything that uses HttpWebRequest. You can see all those errors if you run source version in debug mode.

The difference with latest code is that file manager introduced WebConfigurationManager.OpenWebConfiguration("~") - this code won't run in medium trust and none of the providers will load.

If you restore old code in "LoadProviders()" method in the Core/Providers/BlogService.cs and recompile - your app will run in medium trust again (with same remote call errors).

 

private static void LoadProviders()
{
	// Avoid claiming lock if providers are already loaded
	if (_provider == null)
	{
		lock (TheLock)
		{
			// Do this again to make sure _provider is still null
			if (_provider == null)
			{
				// Get a reference to the <blogProvider> section
				var section = (BlogProviderSection)WebConfigurationManager.GetSection("BlogEngine/blogProvider");

				// Load registered providers and point _provider
				// to the default provider
				_providers = new BlogProviderCollection();
				ProvidersHelper.InstantiateProviders(section.Providers, _providers, typeof(BlogProvider));
				_provider = _providers[section.DefaultProvider];

				if (_provider == null)
				{
					throw new ProviderException("Unable to load default BlogProvider");
				}
			}
		}
	}
}
Sep 9, 2011 at 5:26 AM

I've always used Windows Live Writer.    I'll restore that code and see what I get with the new stuff.  Thanks for your help!

Sep 9, 2011 at 6:01 AM

This appears to have worked.  Testing now.

Sep 9, 2011 at 6:07 AM

Any idea on why this wouldn't work?

http://www.example.com/image.axd?picture=image_thumb_35.png

 

Of course example.com would be an actual domain.

Sep 9, 2011 at 12:55 PM

As an aside for other that may find this thread relevent to their situation, another hosting company that supports full trust is www.CrystalTech.com aka webservices.theSBA.com (recent name change).  We've been using them for 6+ years and love them for their flexibility and developer support.

-Ron

Sep 10, 2011 at 2:30 AM

So this is what the BlogService/LoadProviders code needs to look like.  The only change is the wrapper around the web.config.

 

private static void LoadProviders()
        {
            // Avoid claiming lock if providers are already loaded
            if (_provider == null)
            {
                lock (TheLock)
                {
                    // Do this again to make sure _provider is still null
                    if (_provider == null)
                    {
                        // Get a reference to the <blogProvider> section
                        var section =
                            (BlogProviderSection) WebConfigurationManager.GetSection("BlogEngine/blogProvider");

                        // Load registered providers and point _provider
                        // to the default provider
                        _providers = new BlogProviderCollection();
                        ProvidersHelper.InstantiateProviders(section.Providers, _providers, typeof (BlogProvider));
                        _provider = _providers[section.DefaultProvider];

                        if (_provider == null)
                        {
                            throw new ProviderException("Unable to load default BlogProvider");
                        }
                    }
                }
            }
            if (_fileStorageProvider == null)
            {
                lock (TheLock)
                {
                    if (_fileStorageProvider == null)
                    {
                        var section = (BlogFileSystemProviderSection)WebConfigurationManager.GetSection("BlogEngine/blogFileSystemProvider");
                        _fileProviders = new BlogFileSystemProviderCollection();
                        ProvidersHelper.InstantiateProviders(section.Providers, _fileProviders, typeof(BlogFileSystemProvider));
                        _fileStorageProvider = _fileProviders[section.DefaultProvider];
                        if (_fileStorageProvider == null)
                        {
                            throw new ProviderException("unable to load default file system Blog Provider");
                        }
                    }
                }
            }
        }

Coordinator
Sep 10, 2011 at 8:09 PM

Cool, glad you got there before I did. Merged into main repository (2.5.0.12) and also trust level set to medium in web.config for debug mode, so we catch errors like this hopefully before commit :)