Custom Configuration Section Handler and Code Access Security

[Guest]

Hi

I've written custom configuration section (inherits from
System.Configuration.ConfigurationSection) to simplify the contents of the
config file and to make life easier when accessing them in code.

The configuration section is contained within the exe (it's a simple test
case!) and everything works well debugging within the IDE or if the
application is deployed on a drive or share that has been granted full trust.
For the share the code group is identified by a url
//servername/share/folder/*.

However if the assembly is given a strong name and a code group with full
trust is created using the public key then it fails with the following
message:

An error occurred creating the configuration section hander for
<sectionhandlername>: That assembly does not allow partially trusted callers.

If I add the AllowPartiallyTrustedCallers to the assembly then it works but
I'd rather not do this!

Any ideas why this exception occurs and how to fix it?

I can't see anything in the documentation that mentions or explains this.

Thanks for your help.

Cheers

Doug

 

[Steven Cheng[MSFT]]

Hi Doug,

From your descirption, you've defined a custom configuration section
handler and use it in your .net application(the class also be compiled to
the main exe assembly), this worked well on local drive but encounter some
assembly loading issue when deploy on a remote share, correct?

As for this problem application, so far the deployed application folder
should only contains two files:

** the application's main exe assembly
** the app.config (exe.config)

correct? I have performed a local test which is a console application use a
custom configuration section handler( defined in the main assembly). After
I deploy the application to a UNC share folder and access from another
box(windows 2003), here are what I got based on the testing:

1. If I grant the unc share folder "FullTrust" through URL evidence, then
the application can work without problem

2. If you do not grant the entire share folder "FullTrust", and only grant
the main assembly "FullTrust" by strong-name evidence, you need to make
sure you always use the strong-name signature(include public key token) in
any configuration setting or code which reference the assembly. For
example, in the app.config's custom configuration section register section,
you need to use full assembly name(with publickey token) when declare the
custom section handler type (as below);

===============
<configuration>
<configSections>
<sectionGroup name="myCustomGroup">
<section
name="myCustomSection"
type="CASSection.CASSection, CASSection, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=04e2c2d696067136"
allowLocation="true"
allowDefinition="Everywhere"
/>
...................
===========================

If you use a private assembly name, it will also cause problem.

You can have a try on your side to see whether this is the cause. If you
have any other finding, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Steven

All your assumptions are correct, I did have the assembly's full name
specified in the config file, although I didn't have the following attributes
set:

allowLocation="true" allowDefinition="Everywhere"

But setting these didn't help.

I've managed to get it working by replacing the following line

Dim configThatFails As MailManagerConfiguration =
CType(ConfigurationManager.GetSection("MailManagerConfiguration"),
MailManagerConfiguration)

with these two

Dim myConfiguation As Configuration =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)

Dim config As MailManagerConfiguration =
CType(myConfiguation.GetSection("MailManagerConfiguration"),
MailManagerConfiguration)

Any idea why the first way fails but the second way works?

Thanks for your help.

Cheers

Doug

 

[Steven Cheng[MSFT]]

Thanks for your reply Doug,

I've tried both of the two coding approach in my local project, however, it
seem in both cases the application can work well as long as I add the code
group(that grant the UNC share path or the strong-name "Fulltrust"
permission). Therefore, I'm wondering the problem maybe specific to
particular machine environment. the only difference is that my test project
is built through C#. If you want, I can send my test c# project to you for
testing.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Steven

Feel free to send me your test project and I'll set the trust up to see what
happens! C# is fine, I actually prefer it! Only working in VB as the
developers on this project only speak VB!

This code fails on at least 3 machines, 2 of which are the same base build
but the 3rd one is in the states and so is a completely different build.

What I find strange is that when trusting the UNC share they both work but
by trusting the public key only one works, but I know that the assembly is
trusted as if I remove the strong name trust then they both fail. It looks
like the permissions are ignored on the call to
ConfigurationManager.GetSection which doesn't make sense to me.

Here's the code (with line numbers) and the stack trace which shows that
lines 15 and 16 execute fine, but line 18 throws an exception:

15 Dim myConfiguation As Configuration =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)
16 Dim config As MailManagerConfiguration =
CType(myConfiguation.GetSection("MailManagerConfiguration"),
MailManagerConfiguration)

18 Dim configSection As Object =
ConfigurationManager.GetSection("MailManagerConfiguration")

H:\ConfigurationTests\ConfigurationExample>ConfigurationExample.exe

Unhandled Exception: System.Configuration.ConfigurationErrorsException: An
error occurred creating the configuration section handler for
MailManagerConfiguration: That assembly does not allow partially trusted
callers.
(H:\ConfigurationTests\ConfigurationExample\ConfigurationExample.exe.config
line 27) ---> System.Security.SecurityException: That assembly does not allow
partially trusted callers.
at
System.Security.CodeAccessSecurityEngine.ThrowSecurityException(Assembly asm,
PermissionSet granted, PermissionSet refused, RuntimeMethodHandle rmh,
SecurityAction action, Object demand, IPermission permThatFailed)
at System.Reflection.MethodBase.PerformSecurityCheck(Object obj,
RuntimeMethodHandle method, IntPtr parent, UInt32 invocationFlags)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
at
System.Configuration.TypeUtil.InvokeCtorWithReflectionPermission(ConstructorInfo ctor)
at
System.Configuration.RuntimeConfigurationRecord.RuntimeConfigurationFactory.CreateSectionImpl(RuntimeConfigurationRecord
configRecord, FactoryRecord factoryRecord, SectionRecord sectionRecord,
Object parentConfig, ConfigXmlReader reader)
at
System.Configuration.RuntimeConfigurationRecord.RuntimeConfigurationFactory.CreateSectionWithRestrictedPermissions(RuntimeConfigurationRecord
configRecord, FactoryRecord factoryRecord, SectionRecord sectionRecord,
Object parentConfig, ConfigXmlReader reader)
at System.Configuration.RuntimeConfigurationRecord.CreateSection(Boolean
inputIsTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord,
Object parentConfig, ConfigXmlReader reader)
at System.Configuration.BaseConfigurationRecord.CallCreateSection(Boolean
inputIsTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord,
Object parentConfig, ConfigXmlReader reader, String filename, Int32 line)
The action that failed was:
LinkDemand
The assembly or AppDomain that failed was:
System.Configuration, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a
The Zone of the assembly that failed was:
MyComputer
The Url of the assembly that failed was:
file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
--- End of inner exception stack trace ---
at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[]
keys, SectionInput input, Boolean isTrusted, FactoryRecord factoryRecord,
SectionRecordsectionRecord, Object parentResult)
at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord
factoryRecord, SectionRecord sectionRecord, Object parentResult, Boolean
getLkg, Boolean getRuntimeObject, Object& result, Object& resultRuntimeObject)
at
System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String
configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject,
Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at
System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String
configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject,
Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at
System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String
configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject,
Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at System.Configuration.BaseConfigurationRecord.GetSection(String
configKey,Boolean getLkg, Boolean checkPermission)
at System.Configuration.BaseConfigurationRecord.GetSection(String
configKey)
at
System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
at System.Configuration.ConfigurationManager.GetSection(String sectionName)
at ConfigurationExample.Program.Main() in
J:\Development\Doug\VS2005\Projects\TestApps\ConfigurationExample\ConfigurationExample\Program.vb:line 18

H:\ConfigurationTests\ConfigurationExample>

 

[Steven Cheng[MSFT]]

Hi Doug,

I have sent a mail with the test project to you. If you do not receive it,
please feel free to let me know. And you can reach me through the email in
my signature (remove "online").

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Steven

Thanks for the code and yes it does work on my system. I implemented it in
VB.NET and it too worked.

So I stated to look at the differences between the code you supplied and the
code I had originally used and I've found the problem.

If the section handler has the public modifier applied then the call to
ConfigurationManager.GetSection fails. To prove this I've changed the
modifier on the CASSection class in your project and it too fails, if I reset
it back to private then it works.

Now there's no reason why the section handler needs to be public so setting
it to private is fine, but I don't understand why
ConfigurationManager.GetSection fails whilst calling GetSection on a
Configuration object returned by ConfigurationManager.OpenExeConfiguration
works.

Also shouldn't there be a warning about not declaring section handers as
public classes?

Thanks for your help.

Cheers

Doug

 

[Steven Cheng[MSFT]]

Thanks for your reply Doug,

This does be an important hint, as I didn't expect this difference will
cause the problem. I'll test it on my side to verify it and let you know
the result or any further info.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hi Doug,

I've performed some further test and the result I got seems like what
you've found. I'll look for our internal issue catalog to see whether there
is anything existing one documented on this. And will update you if I get
any new info.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.