Почему нет встроенной роли базы данных «хранимых процедур»?

Я всегда задавался вопросом, почему список ролей базы данных (db_datareader, db_datawriter, db_ddladmin и т. Д.) Никогда не включал db_storedprocedureexecutor. Другие имеют смысл, но похоже, что они могут предоставить возможность выполнять все сохраненные процедуры конкретному пользователю (без предоставления им db_owner, что является единственным способом сделать то же самое) было бы удобной вещью.Почему нет встроенной роли базы данных «хранимых процедур»?

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

Если у меня есть учетная запись службы приложений и несколько хранимых процедур, которые идут вместе с моим приложением, я должен предоставлять права явно каждому SP (так как я не хочу предоставлять базу данных службы службы приложений DBO), тогда как Я могу использовать роль, позволяющую им обновлять/удалять все, что они хотят.

Хотя он изначально казался очевидным, я теперь не уверен, почему эта роль отсутствует на сервере базы данных - может кто-нибудь предложить объяснение, почему это ужасная идея (как я предполагаю, или она уже существует)?

EDIT:

Кажется, я не только один с этим ожиданием - и it's worked around with a handful of T-SQL (кажется, что вы можете предоставить одеяло ВЫПОЛНИТЬ право, которое я не знал, вы могли бы сделать), который как раз оставляет меня недоумением, почему это не стандарт!

источник

2010-11-21 SqlRyan

мне тоже! В основном мы создаем собственную роль 'db_executor', смоделированную после' db_datareader', чтобы обойти это. Но да: почему это не в базовом пакете SQL Server? Не знаю ... то же самое, что: почему существует каталог 'sys.procedures', но нет' sys.functions' ... вещи, которые заставляют вас идти: hmmm ........ –

Если вы используете схемы, то у вас есть только GRANT EXECUTE ON SCHEMA::storedprocschema

например CREATE PROC storedprocschema.DoStuff ...

Как почему, не знаю ...

источник

2010-11-21 19:24:26 gbn

В настоящее время мы используем только DBO, поэтому этот шаг на самом деле не применяется, поскольку я могу сделать «GRANT EXECUTE TO User», и это гранты выполняются на все в dbo. Я понимаю, что вы говорите, хотя, используя ваш метод, мы могли бы изолировать SP, к которым мы хотим, чтобы пользователь нашего приложения имел доступ, и затем GRANT EXECUTE на всей схеме. Интересная идея! – SqlRyan

@ rwmnau: Мы сделали это для каждого клиента: WebGui, Desktop, ThisSystem, ThatSystem и т. Д. Таблицы данных. Внутренние процессы в Helper и т. Д. Я также должен был спросить [это] (http://stackoverflow.com/questions/2212044/sql-server-how-to-permission-schemas), чтобы понять это ... – gbn

-1

Потому что, если вы можете выполнить все хранимые процедуры, вы можете выполнить sp_addrolemember, и вы можете делать все, что может сделать database_owner.

источник

2010-11-21 19:24:16 Andomar

Простите, неправда. Вам понадобится [db_securityadmin] (http://msdn.microsoft.com/en-us/library/ms188685%28SQL.90%29.aspx) для запуска [sp_addrolemember] (http://msdn.microsoft.com/) en-us/library/ms187750% 28SQL.90% 29.aspx) См. раздел «Разрешения» – gbn

Почему нет встроенной роли базы данных «хранимых процедур»?

ответ

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