☰

Cambiar el propietario de la base de datos en SQL Server 2008; ¿Problemas con CLR según el método utilizado?

tag-icon • tag-icon sql-server security database-administration permissions
Cambiar el propietario de la base de datos en SQL Server 2008; ¿Problemas con CLR según el método utilizado?

Adjunté una base de datos e intenté cambiar el propietario a un inicio de sesión válido.

Utilicé la declaración: ALTERAR LA AUTORIZACIÓN EN la base de datos::my_db_name TO "sa". Las propiedades de la base de datos mostraron que el nuevo propietario era 'sa', sin embargo, todavía recibía errores de permiso para ensamblados CLR sin restricciones (0x80FC80F1, 0x8013150A), algo relacionado con problemas de confianza en los ensamblados.

Resolví el problema usando la declaración: EXEC sp_changedbowner 'sa'; para cambiar el propietario de la base de datos.

Mi pregunta es, ¿cuál es la diferencia entre estos dos métodos para cambiar el propietario de la base de datos? ¿Son equivalentes? Me parece claro que sp_changedbowner está haciendo algo más/correcto que la declaración de autorización de modificación no está haciendo.

En caso de que estés interesado... antes de arreglar las cosas con sp_changedbowner, intenté:

  • establecer la propiedad confiable de la base de datos en ON; de hecho, hice esto varias veces; Sé que es un requisito ejecutar ensamblados CLR personalizados sin restricciones y sin firmar
  • cambiar el propietario de cada ensamblaje CLR a dbo, ya que el propietario estaba en blanco, pero aparentemente dbo ya era el propietario, y siempre está en blanco en SSMS.
  • cambiar el propietario de cada ensamblaje CLR por otro, pero eso no funciona, porque los ensamblajes con ensamblajes dependientes parecen necesitar siempre el mismo propietario; pero es imposible cambiar el propietario simultáneamente en ambos con la interfaz proporcionada.
  • llamando a CONCEDER MONTAJE INSEGURO a [sa]; aparentemente no puedes otorgar permisos a esa cuenta integrada, junto con algunas otras; ya tienen permiso
  • llamar a GRANT UNSAFE ASSEMBLY a [NT AUTHORITY\NETWORK SERVICE] (la cuenta que llama a los métodos en los ensamblados); no hubo errores, pero no pareció lograr nada (¿tal vez cambió el número de error? Sin embargo, el mensaje nunca cambió).
  • ...y probablemente algunas otras cosas que no recuerdo.

Respuesta1

En tu lista no veo que configurar la base de datos sea confiable, así que supongo que olvidaste este paso:

ALTER DATABASE my_db_name SET TRUSTWORTHY ON;

Pero tal vez no...

Consultando con este artículo:http://support.microsoft.com/kb/918040parece que efectivamente sugieren usar sp_changedbowner en lugar de ALTER AUTHORIZATION. Pero el hecho es que hace exactamente lo mismo (sp_changedbowner llama ALTER AUTHORIZATION en secreto). La diferencia es que también elimina los "alias" para el usuario dbo (funcionalidad obsoleta de todos modos) y además fuerza un punto de control de la base de datos. Esa última pieza puede ser la que estás buscando.

Respuesta2

Creo ALTER_AUTHORIZATIONy sp_changedbownerambos pueden cambiar la propiedad del objeto de la base de datos. La diferencia entre los comandos, por supuesto, es que ALTER_AUTHORIZATIONpueden cambiar otras cosas (como la propiedad de las tablas), mientras que sp_changedbownersolo sirve para cambiar el propietario de la base de datos.

Sin embargo, el comportamiento que indicaste suena muy extraño. ¿Puedes replicarlo?

información relacionada