Должно ли быть дано разрешение CONTROL для хранимой процедуры в SQL Server 2005?

Question

У меня проблема с предоставлением разрешений EXECUTE для определенной хранимой процедуры в SQL Server 2005. Некоторые из тестировщиков запутались с разрешениями - и обнаружили, что, если они также предоставили разрешения CONTROL для хранимой процедуры - то все прошло нормально. Теперь они убеждены, что предоставление разрешений CONTROL - это путь.

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

Я прав? Кто-нибудь знает какие-либо документы, в которых говорится об этом?

Заранее спасибо.

Подробнее в ответ на комментарии: Хранимая процедура выполняет несколько удалений. Сначала он удаляет все записи, которые были бы осиротевшими из-за удаляемой «основной» записи, а затем окончательно удаляет родительскую запись.

Кроме того, ошибка, которую мы видим, говорит о том, что у пользователя недостаточно прав - или Хранимая Процедура не существует. Мы уже подтвердили, что используем правильного пользователя и что разрешения EXECUTE были предоставлены этому пользователю.

Answer 1

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

Из документации по SQL Server для EXECUTE AS:

CALLER Указывает операторы внутри модуль выполнен в контексте вызывающего модуля. Пользователь исполняющий модуль должен иметь соответствующие разрешения не только на сам модуль, но и на любом объекты базы данных, на которые ссылаются по модулю.

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

Если вы создаете процедуру с EXECUTE AS OWNER, вам не нужно предоставлять никаких разрешений, кроме EXECUTE для процедуры.

Answer 2

Если вам нужно только выполнить хранимую процедуру, очевидно, что разрешение CONTROL - это , а не . Да, работает, так же, как работает ваш веб-сайт под учетной записью локальной системы.

Если лицо, предоставившее разрешение EXECUTE, также является владельцем затронутых таблиц, тогда не должно быть проблем с выполнением sp. В противном случае вам следует предоставить явные разрешения или рассмотреть возможность изменения владельца с помощью инструкции ALTER AUTHORIZATION.

Для управления бонусами создайте роль базы данных, чтобы применять явные разрешения вместо того, чтобы назначать их непосредственно пользователям.

Answer 3

Выполнить должно быть все, что нужно.

Хранимая ли процедура обращается к таблице за пределами базы данных, в которой она находится?

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

Answer 4

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