Início / dba / Perguntas / 188269
Accepted
Kenneth Fisher
Asked: 2017-10-12 13:36:52 +0800 CST

Qual é a diferença entre o usuário `dbo` e o proprietário do banco de dados armazenado em sys.databases

  • 772

Recentemente, tivemos uma pergunta em que o usuário dboem um banco de dados tinha um sidque não correspondia ao owner_sidarquivo sys.databases. Entendo como o proprietário do banco de dados é diferente dos membros da função db_owner, mas sempre pensei que o usuário dbofosse o proprietário real do banco de dados. Não é esse o caso? E se sim, existem diferenças reais entre dboe o que está dentro sys.databases?

sql-server security

1 respostas

  1. Best Answer

    Eu sempre pensei que o usuário dboera o proprietário real do banco de dados.

    Isso é (ou pelo menos deveria ser) correto. O nome "dbo" desse usuário nunca muda, mas o SID subjacente muda dependendo de quem criou o banco de dados ou de quem ele foi definido para ser via sp_changedbowner (inclusive, SQL Server 2005) ou ALTER AUTHORIZATION (começando com SQL Servidor 2008).

    Em todos esses três casos, o registro sys.databasestambém é alterado para que sejam mantidos em sincronia. No entanto, ao restaurar um banco de dados, seja de outro sistema ou da mesma instância, mas de um banco de dados que foi submetido a backup / desanexado antes de um desses 2 comandos SQL serem executados para alterar o proprietário, após RESTORE ou anexar, haverá seja uma incompatibilidade entre a owner_sidcoluna sys.databasese o "dbo" sidnesse sys.database_principalsbanco de dados.

    Até onde eu sei, o registro em sys.database_principalscada banco de dados é o proprietário realowner_sid , e a coluna em sys.databasesé uma questão de manutenção de registros/conveniência (semelhante à desnormalização; sem sys.databaseso sistema precisaria fazer consultas separadas em todos os bancos de dados para obter essa informação, sempre que solicitado!) e segurança. Uma coisa para a qual ele é usado é identificar um banco de dados potencialmente prejudicial/inválido restaurado/anexado se esses registros não corresponderem. Tentar acessar assemblies SQLCLR marcados como EXTERNAL_ACCESSou UNSAFEnão serão carregados se alguém tiver escolhido a rota menos segura de habilitação TRUSTWORTHY, pois depende do SID "dbo", pois ele precisa corresponder a um logon que tenha o EXTERNAL ACCESS ASSEMBLYouUNSAFE ASSEMBLYpermissão. E quando há uma incompatibilidade no SID entre essas duas exibições do catálogo do sistema, não é possível determinar qual usar e é usado como um sinal de alerta para um possível problema de segurança. Na verdade, eu testo essa condição no script de instalação do SQL# para alertar alguém para fazer a alteração apropriada, apenas para que eles não tenham que perder tempo caçando-o caso o SQL Server reclame disso em algum momento.

    • 8

relate perguntas