Um usuário poderá acessar objetos em outros esquemas quando você conceder a permissão ALTER em um esquema para o usuário no SQL Server 2005

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 914847
Este artigo foi arquivado. É oferecido "como está" e não será mais atualizado.
Sintomas
Quando você concede a permissão ALTER em um esquema para um usuário do Microsoft SQL Server 2005, o usuário pode ser capaz de acessar objetos em outros esquemas. Esse problema pode ocorrer mesmo se o acesso para os esquemas explicitamente é negado a esse usuário.

Por exemplo, esse problema pode ocorrer nas seguintes situações.

Observação Esses cenários supõem que um usuário, conhecido como U1, tem a permissão ALTER no esquema S1. U1 acesso negado a um objeto de tabela, conhecido como T1, no esquema S2. O esquema de S1 e o esquema de S2 são de propriedade o mesmo proprietário.
  • U1 tem a permissão CREATE PROCEDURE no banco de dados e a permissão EXECUTE no esquema S1. Portanto, U1 pode criar um procedimento armazenado e acessar T1 no procedimento armazenado.
  • U1 tem a permissão CREATE SYNONYM no banco de dados e a permissão Selecionar no esquema S1. Portanto, U1 pode criar um sinônimo no esquema S1 para T1 e, em seguida, acessar T1, usando o sinônimo.
  • U1 tem a permissão CREATE VIEW no banco de dados e a permissão Selecionar no esquema S1. Portanto, U1 pode criar um modo de exibição no esquema S1 para consultar dados de T1 e, em seguida, acessar T1, usando o modo de exibição.
Causa
Esse problema ocorre porque a propriedade cadeias ignoram permissões em objetos referenciados quando os objetos têm o mesmo proprietário. A permissão ALTER permite que o usuário criar objetos que irão ser possuídos pelo proprietário do esquema. Portanto, quando você cria um objeto no esquema de outro usuário, o objeto recém-criado pode estender as permissões do usuário que criou.
Como Contornar
Recomendamos que você considere esses cenários quando você conceder a permissão ALTER em um esquema cujo proprietário também possui outros esquemas. Evite conceder a permissão ALTER em um esquema, a menos que seja necessário. Se você deve conceder a permissão ALTER, considere alterar o proprietário do esquema para um objeto específico que não possui outros esquemas.
Situação
Esse comportamento é por design.
Mais Informações
Instruções Transact-SQL a seguir demonstram os três cenários mencionados na seção "Sintomas". Para usar este exemplo, execute as instruções a seguir no SQL Server Management Studio.
-- Create the test environment.  USE masterGOCREATE DATABASE testGOUSE testGOCREATE LOGIN TestUser WITH PASSWORD = 'Password';GOCREATE USER TestUserGOCREATE SCHEMA secretGOCREATE SCHEMA visibleGOCREATE TABLE secret.t (c INT);GoINSERT INTO secret.t VALUES (42);GODENY SELECT ON secret.t TO TestUser;GRANT ALTER ON SCHEMA::visible TO TestUser;GO--########-- Scenario 1-- Grant permissions.GRANT EXECUTE ON SCHEMA::visible TO TestUser;GRANT CREATE PROCEDURE TO TestUser;GO-- Access the denied object.EXECUTE AS USER = 'TestUser';SELECT USER_NAME() AS CURRENT_USER_NAME;GOCREATE PROCEDURE visible.sptest ASBEGINSELECT * FROM secret.tENDGOSELECT 'Scenario 1: Executing procedure'EXEC visible.sptestGO-- Scenario 2-- Clear the state.REVERTGODROP PROCEDURE visible.sptestREVOKE EXECUTE ON SCHEMA::visible TO TestUser;REVOKE CREATE PROCEDURE TO TestUser;GO-- Grant permissions.GRANT SELECT ON SCHEMA::visible TO TestUser;GRANT CREATE SYNONYM TO TestUser;GO-- Access the denied object.EXECUTE AS USER = 'TestUser';SELECT USER_NAME() AS CURRENT_USER_NAME;GOCREATE SYNONYM visible.mytestFOR secret.t;GOSELECT 'Scenario 2: Querying from the synonym'SELECT * FROM visible.mytestGO-- Scenario 3-- Clear the state.REVERTGODROP SYNONYM visible.mytestREVOKE SELECT ON SCHEMA::visible TO TestUser;REVOKE CREATE SYNONYM TO TestUser;GO-- Grant permissions.GRANT SELECT ON SCHEMA::visible TO TestUser;GRANT CREATE VIEW TO TestUser;GO-- Access the denied object.EXECUTE AS USER = 'TestUser';SELECT USER_NAME() AS CURRENT_USER_NAME;GOCREATE VIEW visible.myviewASSELECT * FROM secret.tGOSELECT 'Scenario 3: Querying from the newly created view'SELECT * FROM visible.myview-- Remove the test database.REVERTGOUSE masterGODROP LOGIN TestUserGODROP DATABASE testGO
Referências
Para obter mais informações sobre cadeias de propriedade, consulte o tópico "Propriedade cadeias" nos manuais online do SQL Server 2005.

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 914847 - Última Revisão: 12/09/2015 04:42:49 - Revisão: 1.1

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition

  • kbnosurvey kbarchive kbmt kbtshoot kbexpertiseadvanced kbsql2005engine kbprb KB914847 KbMtpt
Comentários