none
SqlClientPermission failure in assembly loaded via reflection RRS feed

  • Question

  •  I am having a really tough time with a problem.  I have a web application that I have just modified that allows customers to supply custom assemblies that they can use to hook into an entity save pipeline.  These custom assemblies are loaded via reflection when an entity is persisted to the database.  They refer to a common DAL assembly that handles all of the data access.

    I have a test server (Win2k3) where this system works flawlessly.  Now that I've pushed it out to my production server cluster (one Win2k3 and one Win2k8), my custom assembly bombs the first time it calls a DAL method that accesses the database (SQL2005).  The log information that I gather indicates that there is a failure in getting a SqlClientPermission.  Contrary to best practices, I have my web app running in Full Trust.  My custom assembly is strong named.

    Are there any suggestions to where I can look for differences between my test server config and my production server configs?  If this is not the proper forum, which one is?

    Thanks,

    Matthew

    Friday, July 31, 2009 7:08 PM

All replies

  • It would appear now that this is a Win2k8 vs Win2k3 issue since I no longer get any exceptions in the logs from the Win2k3 server in our cluster.

    Basically, what happens is that our entity save pipeline checks to see if the entity type being saved implements a certain interface.  If so, then the application goes out to the database to retrieve the assembly and class name of the class that implements the customer-specific pre- and post- save functionality.  Those assemblies are under the "App_Data" folder in an folder called "Assemblies\<companycode>".  The application then loads the assembly; uses reflection to instantiate the proper class from that assembly as an interface, then calls the pre and post save methods on that interface to perform the customer specific actions for that particular entity type.  In our case, this custom action performs some database operations using our DAL (which uses LLBLGen, FWIW) entity classes.

    My initial issue was that I was getting a SecurityException about not allowing partially trusted callers, so I decorated the assemblies that are used with the "AllowPartiallyTrustedCallers" attribute and now seem to have eliminated the problem from my Win2k3 server.

    In my extension assemby that gets loaded, I instantiate a SqlClientPermission and "Assert()" it, but I haven't anywhere actually granted that permission (except that my web app runs in FullTrust).

    Thanks for whatever help you can offer...

    -Matthew

    Here is the .ToString() output of the exception that gets thrown:

    <code>

    Error performing post-save operation on entity 373c595e-843b-45a1-82d0-aa166daf75de of type SS2DAL.EntityClasses.SurveyResponseEntity: SD.LLBLGen.Pro.ORMSupportClasses.ORMQueryExecutionException: An exception was caught during the execution of a retrieval query: Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.. Check InnerException, QueryExecuted and Parameters of this exception to examine the cause of this exception. ---> System.Security.SecurityException: Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
       at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
       at System.Security.CodeAccessPermission.Demand()
       at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
       at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
       at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior)
       at SD.LLBLGen.Pro.ORMSupportClasses.RetrievalQuery.Execute(CommandBehavior behavior)
    The action that failed was:
    Demand
    The type of the first permission that failed was:
    System.Data.SqlClient.SqlClientPermission
    The first permission that failed was:
    <IPermission
    version="1"
    AllowBlankPassword="False">
    <add KeyRestrictions=""
    KeyRestrictionBehavior="AllowOnly"/>
    </IPermission>

    The demand was for:
    <IPermission
    version="1"
    AllowBlankPassword="False">
    <add KeyRestrictions=""
    KeyRestrictionBehavior="AllowOnly"/>
    </IPermission>

    The granted set of the failing assembly was:
    <PermissionSet
    version="1">
    <IPermission
    version="1"
    Access="Open"/>
    <IPermission
    version="1"
    Allowed="ApplicationIsolationByUser"
    UserQuota="512000"/>
    <IPermission
    version="1"
    Flags="Execution"/>
    <IPermission
    version="1"
    Window="SafeTopLevelWindows"
    Clipboard="OwnClipboard"/>
    <IPermission
    version="1"
    PublicKeyBlob="0024000004800000940000000602000000240000525341310004000001000100B55C03865E07BCB230B04EF7D9ACF1E7BF41C618DB1327895C25328446039F51CF237A50989E542D3FA9BB5991D303388C5AAC7AE4E071CD7B42B96B16256FF905EC610107DB2A0872E971253919BA528187489FC89FD083118F562319BF3B66CB79035EC50D2291561D4F2B9733AD5E0ECD9BFF9B80B94C40F5888D4E1C5BDD"
    Name="ProjectHelpers.Extensions"
    AssemblyVersion="2.2009.208.1821"/>
    <IPermission
    version="1"
    Url="file://dc01.bizspeed.datacenter/websites/sitesupervisor files/prjh/ProjectHelpers.Extensions.dll"/>
    <IPermission
    version="1"
    Zone="Internet"/>
    <IPermission
    version="1"
    Level="SafePrinting"/>
    </PermissionSet>

    The assembly or AppDomain that failed was:
    ProjectHelpers.Extensions, Version=2.2009.208.1821, Culture=neutral, PublicKeyToken=4405fd38c7d52787
    The method that caused the failure was:
    SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2 AfterSave(SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2, SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase)
    The Zone of the assembly that failed was:
    Internet
    The Url of the assembly that failed was:
    file://dc01.bizspeed.datacenter/websites/sitesupervisor files/prjh/ProjectHelpers.Extensions.dll
       --- End of inner exception stack trace ---
       at SD.LLBLGen.Pro.ORMSupportClasses.RetrievalQuery.Execute(CommandBehavior behavior)
       at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.ExecuteSingleRowRetrievalQuery(IRetrievalQuery queryToExecute, IEntityFields2 fieldsToFill, IFieldPersistenceInfo[] fieldsPersistenceInfo)
       at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntityUsingFilter(IEntityFields2 fieldsToFetch, IFieldPersistenceInfo[] persistenceInfos, IRelationPredicateBucket filter)
       at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntityUsingFilter(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath, Context contextToUse, IRelationPredicateBucket filter, ExcludeIncludeFieldsList excludedIncludedFields)
       at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntity(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath, Context contextToUse, ExcludeIncludeFieldsList excludedIncludedFields)
       at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntity(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath)
       at ProjectHelpers.Extensions.SurveyResponseSaveHelper.AfterSave(EntityBase2 entity, DataAccessAdapterBase adapter)
       at SS2.RemoteObjects.DataPortal.EntitySaveWithoutRemoting(EntityBase2 entity, AuditSettings auditSettings, AuthTicket at)  [NDC:(null)]

    </code>

    Friday, July 31, 2009 7:09 PM
  • Did you ever find an answer to this? We have a virtually identical situation (ASP.NET site with custom plug-ins implementing interfaces that we instantiate via reflection) and are having the same error. We're unable to replicate the problem on our local test servers (2003 or 2008), but have had several clients encounter the problem. In some cases we've been able to fix it by toggling the trust level on the site/virtual directory to full trust, and another was fixed by running aspnet_regiis -i, but in another case neither of these were successful and I'm just stumped. One difference is that our plug-ins aren't always guaranteed to be signed, so we can't use the caspol utility to explicitly set the trust level on the assembly. If you have any information, I'd love to trade ideas!

    Thanks

    Tuesday, August 25, 2009 3:39 PM