Enterprise Library y la Registry

 Esta  vez quiero compartir una mano que le dí a Mauro, empleado de uno de los bancos más grandes del mundo, que estaba teniendo problemas con un desarrollo basado en Enterprise Library por accesos ilegales a la Registry

A Mauro le extrañaba que, siendo que EntLib resume las mejores prácticas, "se haya pasado por alto un principio tan elemental como el acoplamiento (en este caso de la Registry del SO)". El servicio publicado en el IIS se apoyaba en dos app blocks: Configuration y Data Access. Sin embargo, cada invocación terminaba con lo que sigue


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: Requested registry access is not allowed.

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: Requested registry access is not allowed.]
   Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable) +473
   System.Diagnostics.EventLog.CreateEventSource(String source, String logName, String machineName, Boolean useMutex) +445
   System.Diagnostics.EventLog.CreateEventSource(String source, String logName, String machineName) +11
   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.PerformanceCounterInstances.ReportCounterFailure(String message)
   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.PerformanceCounterInstances..ctor(String categoryName, String counterName, Boolean createNewInstance)
   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.InstrumentedEvent.AddPerformanceCounter(String category, String[] counterNames, Boolean createNewInstance)
   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.InstrumentedEvent.Initialize(String counterCategory, String[] counterNames, Boolean createNewInstance, String eventLogSource, EventLogIdentifier[] eventIds)
   Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.InstrumentedEvent..ctor(String counterCategory, String[] counterNames, Boolean createNewInstance)
   Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataServiceEvent..ctor(String[] counterNames)
   Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataCommandFailedEvent..ctor(String[] counterNames)
   Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataCommandFailedEvent..cctor()


Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET Version:1.1.4322.573

 


Días más tarde, en el architect forum de junio pasado, David -arquitecto de Soluziona– estaba mencionando pros y contras de EntLib, y también destacó como un drawback el hecho de la dependencia en la Registry, que obliga a tener permisos extras en el servidor (algo que compromete la seguridad)

Sin embargo, esta aparente dependencia puede evitarse y renovar la confianza en la EntLib del grupo PAG

Si vemos con atención el stack trace, uno de los métodos invocados es AddPerformanceCounter en la clase Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.InstrumentedEvent. Este método a su vez irá invocando a otros, los cuales van a intentar acceder a la Registry, al log de eventos, etc. Para acceder en forma programática el proceso cliente debe poseer permisos y no los tiene. De ahí que salte la excepción mortal

La buena noticia es que el método AddPerformanceCounter como algunos otros en la EntLib de características similares, están decorados con el atributo [Conditional("USEPERFORMANCECOUNTER")]. Este atributo lo que significa es que, sólo si el símbolo USEPERFORMANCECOUNTER está definido al momento de la compilación, la llamada al método será compilada. Será entonces cuestión de compilar la EntLib sin ese símbolo

En efecto, son tres los símbolos de compilación que generan código que requiere accesos especiales: USEWMI;USEEVENTLOG;USEPERFORMANCECOUNTER. Los tres son símbolos de compilación condicional del proyecto Common, de la EntLib

Está claro que sacarlos resta funcionalidad al conjunto. Cuál es la funcionalidad que se pierde? Trazabilidad vía Windows Management Instrumentation (WMI), vía log de eventos y acceso al contador de performance. Sobra aclarar que si se desea hacer uso de estos tres recursos del sistema, la única alternativa es asignar los respectivos permisos

El caso que Mauro me presentaba no precisaba acceso a los mismos

 

Espero, con este tip, estar ayudando a más de un desarrollo trabado por este problema

Esta entrada fue publicada en patterns and practices. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s