Почему хранимая процедура не может прочитать таблицу из другой базы данных (я должен неправильно использовать GRANT и DENY)

Question

У меня есть две базы данных Microsoft SQL Server 2000, и одна хранимая процедура пытается прочитать данные из другой. Раньше это работало нормально, но так как я стал заботиться о безопасности и изменил имя входа (пользователь SQL) с «db owner» на «denydatareader», вызов завершается неудачей.

Я могу заставить все работать, если использую группу «datareader», но, поскольку я не хочу, чтобы этот логин имел доступ для чтения к пользовательским таблицам (ASP используют только procs), я подумал, что это неразумно. Это также работает, если я беру пользователя из всех групп !!! Это нормально?

<Ч />

Одна база данных называется «Внутренняя» и имеет таблицу «Материал». Другой называется «WebFacing» и имеет хранимую процедуру «Get_Some_Data», которая выбирается из «Internal..Stuff».

Я выполнил эту команду во внутренней базе данных:
GRANT SELECT ON Stuff TO magnus

Я запустил этот файл в базе данных WebFacing:
GRANT EXECUTE ON Get_Some_Data TO magnus

Мой ASP использует логин SQL 'magnus' и подключается к базе данных 'WebFacing'. Когда он пытается выполнить процедуру EXEC, он выдает ошибку:
SELECT permission denied on object 'Stuff', database 'Internal', owner 'dbo'.

<Ч />

(Прошу прощения, если это глупый вопрос, но меня толкнули в глубокий конец и я узнал только о GRANT и DENY вчера. Я пробовал поискать в Google ...)

Answer 1

Ассоциирование логинов SQL с группами / ролями (или нет) - это скорее удобная функция для человека, который должен следить за разрешениями для базы данных. Поскольку вы новичок во всем этом, я бы сначала сосредоточился на том, чтобы получить правильные разрешения для конкретного имени входа, прежде чем беспокоиться об управлении разрешениями с помощью групп / ролей.

Одна из вещей, которая меня устроила, когда я впервые начал работать с разрешениями SQL Server, заключалась в понимании того, были ли разрешения, используемые для выполнения хранимой процедуры, такими же, как у входа SQL, используемого для вызова proc, или связанного входа SQL с созданием самого proc. Термин для этого (какой набор учетных данных и связанных разрешений используется для выполнения кода процедуры) называется «контекстом безопасности», в котором выполняется хранимый процесс. Я недавно работал с MySQL, но если я правильно помню, контекст безопасности по умолчанию, используемый для выполнения хранимой процедуры на SQL Server, - это CALLER, а не владелец proc. Это всегда казалось мне нелогичным, потому что мне казалось, что одним из ключевых преимуществ использования хранимых процедур должна быть возможность предоставлять только разрешения EXEC для определенных процедур входам в CALLER. Но когда я пытался сделать это таким образом, я неизбежно получал ошибки разрешений, потому что учетные данные, которые я использовал для вызова процедуры, не имели бы разрешений, необходимых для завершения одной или нескольких операций, содержащихся в хранимой процедуре.

Если вы используете SQL Server 2005 и хотите иметь возможность предоставлять только полномочия EXEC для учетных данных CALLER, то эта статья может помочь пролить свет на то, как это сделать. На мой взгляд, это «правильный» способ сделать что-то, хотя я уверен, что, возможно, есть другие, которые могут не согласиться (хотя я бы, вероятно, придерживался своего аргумента по этому вопросу).

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

Answer 2

Вы можете включить владение базой данных Croos, не предоставляя права доступа к таблице, которую вызывает ваш спрок. Но используйте на свой страх и риск. Я использую его для сценария, который вы описываете:

изменить имя базы данных, установить db_chaining на

Answer 3

Пользователь строки подключения!

Определенно проблема с разрешениями, но кто?

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

Answer 4

Когда вы переходите к другой базе данных в том же экземпляре, каждая «команда» имеет разрешения для своих таблиц и представлений, которые оцениваются целевой базой данных в одном и том же контексте, прежде чем ее разрешают запускать.

В отличие от этого, он полностью находится в той же базе данных, что и SP, где разрешения SELECT не требуются для таблиц, на которые есть ссылка в SP, для которых у вас есть права EXEC.

Вы можете использовать EXECUTE AS для выполнения от лица, обладающего правами, или другой альтернативой является создание VIEW во второй базе данных, которая возвращает только нужные столбцы, или установка разрешений на уровне столбцов для таблиц, или создать SP и вызвать его (вам нужно будет вставить результаты во временную таблицу, так что это не очень эффективно).