2008-09-29 2 views
2

У меня есть несколько хранимых процедур в моей базе данных, которые используются для загрузки данных из датамарта, размещенного в отдельной базе данных. Эти процедуры, как правило, заключаются в следующем:Сохранение процедуры Собственность Цепочка


CREATE PROCEDURE load_stuff 
WITH EXECUTE AS OWNER AS 
INSERT INTO my_db.dbo.report_table 
(
    column_a 
) 
SELECT 
    column_b 
FROM data_mart.dbo.source_table 
WHERE 
    foo = 'bar'; 

Это нормально работает при выполнении запроса в SQL Server Management Studio. Когда я пытаюсь выполнить их с помощью EXEC load_stuff, процедура выходит из строя с предупреждением безопасности:

Директор сервера «the_user» не может получить доступ к базе данных «data_mart» в контексте текущей безопасности.

ВЛАДЕЛЬЦЕМ sproc является dbo, который является the_user (ради нашего примера). ВЛАДЕЛЕЦ обеих баз данных также является the_user, а the_user сопоставляется с dbo (что и должно делать SQL Server).

Почему я должен видеть эту ошибку в SQL Server? Это потому, что пользователь, о котором идет речь, является псевдонимом как dbo, и я должен использовать другую учетную запись пользователя для доступа к данным с междоменной базы данных?

Редактировать Я понимаю, что это связано с тем, что SQL Server отключает перекрестную привязку к базе данных по умолчанию, что хорошо. Однако я не уверен в лучшей практике в этой ситуации. Если у кого-то есть какой-либо вклад в лучшую практику для этого сценария, было бы весьма полезно.

Редактировать 2 Возможное решение было установить TRUSTWORTHY ON на обеих базе данных. Это позволяет ограничить цепочку прав собственности между двумя базами данных, не прибегая к полной цепочке связывания базы данных.

ответ

2

Почему бы не удалить EXECUTE AS OWNER?

Как правило, мой пользователь, выполняющий SP, будет иметь соответствующие права в обеих базах данных, и мне не нужно это делать вообще.

0

На самом деле DBO - это роль (вы можете рассматривать ее как группу пользователей), а не пользователь в себе. (Если вы не можете подключиться к SQL SERVER с помощью dbo: passwordfordbo, это не пользователь).

Как правило, в чудесном мире Sql Server, если вы предоставляете право пользователя XXXXXXXXXXXX, то X получает право выполнять всю задачу Y, даже если у него нет всех прав на все объекты, используемые в Y.

Это чрезвычайно полезная функция для инкапсуляции бизнес-логики в хранимую процедуру. (У вашего пользователя нет доступа к таблице, но они могут ВЫПОЛНИТЬ одну сохраненную процедуру).

Когда мы говорим о «привязке собственности», это означает следующее (пожалуйста, поправьте меня, если я ошибаюсь) - Если цепочка прав собственности отключена: право на выполнение процедурыX будет работать до тех пор, пока все необходимые объекты находятся в та же база данных - Включена цепочка: эта «привилегия» будет расширяться по отношению ко всем базам данных.

Надежда, что помогает,

+0

На самом деле ДБО является пользователем (а не логин), который сопоставляется с логином уровня экземпляра. db_owner - это роль, о которой вы думаете. – 2009-01-02 12:33:21

1

Там нет необходимости создавать логин, вы можете просто включить гостевой пользователь в целевой БД.

гранта подключиться к гостевому

Это позволяет выполнять пользователь ввести БД под контекстом гостя, а когда «дб цепочка включена доступом не будет проверяться в целевой БД.

Смежные вопросы