Início / dba / Perguntas / 303906
Accepted
BVernon
Asked: 2021-12-14 17:03:58 +0800 CST

As conexões existentes respeitam imediatamente uma alteração na configuração TRUSTWORTHY?

  • 772

Quando você alterar a TRUSTWORTHYconfiguração, as conexões existentes respeitarão imediatamente essa alteração?

Eu tive uma experiência que parece sugerir que as conexões existentes não honram imediatamente a mudança, mas isso não parece certo, então eu gostaria de obter uma confirmação sobre isso para saber com o que estou lidando.

Não durante uma consulta. Quero dizer, se você estiver no SSMS com uma sessão aberta e as configurações forem alteradas, sua próxima consulta será afetada pela alteração nessa mesma sessão?

Eu não tinha certeza de qual banco de dados precisava ser TRUSTWORTHYativado para um processo específico, então estava testando para ver. Desliguei em um banco de dados e ainda funcionou bem. Então eu desliguei no outro banco de dados e ainda funcionou bem. No entanto, o processo não foi executado mais tarde para outro usuário, então eu imediatamente o liguei novamente em ambos os dbs. Achei estranho que o processo fosse executado com sucesso depois que eu o desliguei em ambos os bancos de dados para começar, porque tenho quase certeza de que é necessário estar ativado para um gatilho em um banco de dados poder gravar em uma tabela no outro banco de dados

Estou tentando mudar de ONpara OFF.

sql-server trigger

1 respostas

  1. Best Answer

    As alterações na TRUSTWORTHYconfiguração são realmente perceptíveis, pelo menos entre consultas/instruções, enquanto uma sessão ainda está ativa. Uma alteração de ONto nãoOFF afetará uma consulta em execução (uma alteração de to é irrelevante, pois a consulta nunca teria iniciado se a configuração fosse iniciada como e tal condição produz um erro), nem mesmo se tiver um que executará o "externo " expressão/objeto várias vezes. A consulta em execução pode ser concluída antes que a configuração seja verificada novamente. Eu testei os dois cenários, e o teste para o primeiro cenário (o caso mais óbvio e comum) está abaixo.OFFONOFFOUTER APPLY

    Teste

    CREATE DATABASE [A];
ALTER DATABASE [A] SET RECOVERY SIMPLE, TRUSTWORTHY OFF;

CREATE DATABASE [B];
ALTER DATABASE [B] SET RECOVERY SIMPLE, TRUSTWORTHY OFF;

USE [B];
CREATE TABLE dbo.Stuffs(col1 INT);
INSERT INTO dbo.Stuffs([col1]) VALUES (1);

USE [A];
CREATE TABLE dbo.Here ([col1] INT);

GO
CREATE OR ALTER TRIGGER dbo.[tr_Here_Ins] ON dbo.[Here]
WITH EXECUTE AS N'dbo'
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
    INSERT INTO [B].dbo.[Stuffs] ([col1])
        SELECT [col1]
        FROM   inserted
END;
GO

CREATE USER [Testy] WITHOUT LOGIN;
GRANT INSERT ON dbo.[Here] TO [Testy];

EXECUTE AS USER = N'Testy';

INSERT INTO dbo.[Here] ([col1]) VALUES (1);
/*
Msg 916, Level 14, State 2, Procedure tr_Here_Ins, Line 7 [Batch Start Line XXXX]
The server principal "ALBRIGHT\Solomon" is not able to access the database "B"
under the current security context.
*/


-- In another tab/session:
-- ALTER DATABASE [A] SET TRUSTWORTHY ON;

INSERT INTO dbo.[Here] ([col1]) VALUES (2);
-- Success
SELECT SESSION_USER; -- Testy


-- In the other tab/session:
-- ALTER DATABASE [A] SET TRUSTWORTHY OFF;

INSERT INTO dbo.[Here] ([col1]) VALUES (3);
/*
Msg 916, Level 14, State 2, Procedure tr_Here_Ins, Line 7 [Batch Start Line XXXX]
The server principal "ALBRIGHT\Solomon" is not able to access the database "B"
under the current security context.
*/


REVERT;
SELECT SESSION_USER; -- dbo

SELECT * FROM [B].dbo.[Stuffs];

    Limpar

    USE [master];
DROP DATABASE [A];
DROP DATABASE [B];

    Em relação a qual banco de dados precisa ser TRUSTWORTHYdefinido ONpara evitar certos erros de permissão:

    • Resposta sarcástica (embora também ideal): "nenhum", pois você deve usar a assinatura do módulo (consulte meu site, Module Singing Info , para mais informações). Veja abaixo.
    • Resposta direta: apenas o banco de dados de onde vem a solicitação precisa estar TRUSTWORTHYhabilitado, se for TRUSTWORTHYnecessário. Isso é diferente do Cross-Database Ownership Chaining onde, quando não estiver habilitado para todos os bancos de dados na instância, todos os bancos de dados envolvidos na solicitação precisam estar DB_CHAININGhabilitados.

    Em relação à opção ideal (sem TRUSTWORTHYbase):

    1. Crie um certificado no banco de dados (A) contendo trigger
    2. ALTERo gatilho para remover a WITH EXECUTE AS...cláusula
    3. Assine o gatilho usando ADD SIGNATURE
    4. Copie o certificado (somente chave pública) para o banco de dados (B) no qual o gatilho está gravando
    5. Crie um usuário no outro banco de dados (B) do certificado
    6. Conceda a nova permissão de usuário baseada em certificado INSERTna tabela que está sendo gravada
    7. ALTERo banco de dados (A) com o gatilho para desabilitarTRUSTWORTHY
    • 4

relate perguntas