No se puede agregar un ensamblado SQLCLR a la base de datos, Msg 300

Question

Tengo problemas para agregar un ensamblado SQLCLR a una base de datos, pero un compañero de trabajo no tiene problema. Aunque tenemos diferentes niveles de acceso, no podemos entender por qué recibo el mensaje de error que estoy recibiendo.

Aquí está mi código:

USE [mydatabase] 
GO 

CREATE ASSEMBLY [My.Assembly] 
AUTHORIZATION [dbo] 
FROM 'C:\Program Files\MyStuff\My.Assembly.dll' 
WITH PERMISSION_SET = UNSAFE 
GO 

Y aquí es mi error:

Msg 300, Level 14, State 1, Line 3
UNSAFE ASSEMBLY permission was denied on object 'server', database 'master'.

Pensamientos?

Answer 1

Creo que tienes un problema porque el nombre de usuario no es miembro de sysadmin. MSDN dice: "Si se especifica PERMISSION_SET = UNSAFE, se requiere membresía en la función de servidor fijo sysadmin"

Answer 2

¿Ha alterado las propiedades de la base de datos para establecer la confiabilidad?

ALTER DATABASE Nombre de archivo de datos SET TRUSTWORTHY ON; Desde BOL Como no se puede confiar inmediatamente en una base de datos adjunta a una instancia de SQL Server, la base de datos no puede acceder a recursos fuera del alcance de la base de datos hasta que la base de datos esté explícitamente marcada como confiable. Además, los módulos que están diseñados para acceder a los recursos fuera de la base de datos y los ensamblados con la configuración de permisos EXTERNAL_ACCESS y UNSAFE tienen requisitos adicionales para ejecutarse correctamente.

Answer 3

POR FAVOR, haga no Agregue un inicio de sesión a la sysadmin Función de servidor fijo para poder pasar este error. ¡No es absolutamente necesario!

La respuesta aceptada es incorrecta, no porque no funcione (lo hace), sino porque no hay necesidad de otorgar CONTROL TOTAL EN TODA LA INSTANCIA a un inicio de sesión solo para hacer algo que tiene un permiso específico para . Usted no haría que un Inicio de sesión de Windows sea un Administrador de dominio únicamente con el fin de otorgarle permiso de Eliminar en un recurso compartido o carpeta en particular.

Para que quede claro, esto no es culpa del póster, ya que citaban correctamente la documentación de MSDN. El problema es que la documentación de MSDN para CREATE ASSEMBLY era incorrecta. El documentation for SQL Server 2008 R2 hizo, lamentablemente, indicar que el inicio de sesión tenía que estar en el rol de servidor sysadmin. Sin embargo, it has since been corrected a estado:

If PERMISSION_SET = UNSAFE is specified, requires UNSAFE ASSEMBLY permission on the server.

Este permiso, UNSAFE ASSEMBLY, es el permiso exacto indicado en el mensaje de error:

UNSAFE ASSEMBLY permission was denied on object 'server', database 'master'

Significado, todo lo que se necesita es hacer lo siguiente (una vez) :

USE [master]; 
GRANT UNSAFE ASSEMBLY TO [AD_domain_name\windows_login_name]; -- for Windows Logins 

o:

USE [master]; 
GRANT UNSAFE ASSEMBLY TO [sql_login_name]; -- for SQL Server Logins 

La razón por la que necesita estar en la base de datos [master] es que este permiso es un nivel de servidor, no de nivel de base de datos, que debe aplicarse a los inicios de sesión (que existen en el nivel del servidor) y no a los usuarios (que existen en el nivel de la base de datos).

Y es por esto que el mensaje de error hace referencia a object 'server' (porque se trata de un permiso de nivel de servidor) y database 'master' (porque inicios de sesión existen en la base de datos [master] y sólo se pueden modificar cuando la base de datos actual para la consulta se establece en [master]) .

He probado esto con un inicio de sesión que obtendría el mensaje de error que se muestra en la Pregunta (es decir, Msg 300) al intentar cargar un Ensamblaje marcado como WITH PERMISSION_SET = UNSAFE. Luego concedí ese permiso UNSAFE ASSEMBLY y el inicio de sesión pudo cargar el ensamblaje UNSAFE; no se requirió la membresía sysadmin (o incluso se intentó). Probé esto en: SQL Server 2005 SP4, SQL Server 2008 R2 RTM y SQL Server 2012 SP3.