GRANT EXECUTE для всех хранимых процедур

147

Дает ли следующая команда пользователю "MyUser" разрешение на выполнение ВСЕХ хранимых процедур в базе данных?

GRANT EXECUTE TO [MyDomain\MyUser]

— Чад
источник

244

SQL Server 2008 и выше:

/* CREATE A NEW ROLE */
CREATE ROLE db_executor

/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor

Только для пользователя (не роли):

USE [DBName]
GO
GRANT EXECUTE TO [user]

— Энтони Скотт
источник

28

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

— marc_s

2

Я думаю, что стоит отметить, что вы, userвозможно, должны быть в квадратных скобках. Это было верно в моем случае использования, по крайней мере частично, потому что у моего пользователя был присоединен домен (т. Е. В нем был символ \). редактирование: исправлена

— ошибка с неэкспонированным

1

Почему бы не назначить пользователя на роль db_ddladmin? «Члены предопределенной роли базы данных db_ddladmin могут выполнять любую команду языка определения данных (DDL) в базе данных». - смотрите здесь

— Майкл Тобиш

1

@MichaelTobisch здесь просто нужно выполнить хранимые процедуры. Роль DDL должна использоваться в сценариях создания, изменения, удаления и .... Эти ссылки должны быть полезны: docs.microsoft.com/en-us/sql/relational-databases/security/… и geeksforgeeks.org/sql-ddl-dml-dcl-tcl-commands

— QMaster

2

И следующий уровень добавления пользователя к роли в случае, если это спасает кого-то еще один этап исследования. ALTER ROLE db_executor ДОБАВИТЬ ЧЛЕНА YourUserNameHere

— Piwaf

72

В SQL Server 2005 появилась возможность предоставлять разрешения на выполнение базы данных принципу базы данных, как вы описали:

GRANT EXECUTE TO [MyDomain\MyUser]

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

Вы также можете ограничить, предоставив разрешения на выполнение схемы, если вы хотите быть более детальным:

GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]

— Робин Минто
источник

5

Замечательно иметь возможность делать это с определенной схемой, поэтому

— избегайте

17

В дополнение к ответам выше, я хотел бы добавить:

Возможно, вы захотите предоставить это роли , а затем назначить роль пользователю (-ям). Предположим, вы создали роль myAppRightsчерез

CREATE ROLE [myAppRights]

тогда вы можете дать права на выполнение через

GRANT EXECUTE TO [myAppRights]

на эту роль.

Или, если вы хотите сделать это на уровне схемы:

GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]

также работает (в этом примере роль myAppRightsбудет иметь права на выполнение всех элементов схемы dboвпоследствии).

Таким образом, вам нужно сделать это только один раз, и вы можете легко назначить / отозвать все связанные права приложения для пользователя или от пользователя, если вам потребуется изменить это позже - особенно полезно, если вы хотите создать более сложные профили доступа.

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

— Matt
источник

-5

ПРЕДОСТАВИТЬ ВЫПОЛНИТЬ [РОЛЬ]

Этот наверняка поможет

— Шарон А.С.
источник

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

— ammills01

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

— Кристофер Браун

«Каждый логин принадлежит к общедоступной фиксированной серверной роли, а каждый пользователь базы данных принадлежит к общедоступной роли базы данных. Когда логин или пользователь не получил или не получил определенных разрешений для защищаемого объекта, логин или пользователь наследуют разрешения, предоставленные для «Это безопасно». Таким образом, предоставление любых разрешений для PUBLIC означает предоставление этих разрешений всем пользователям. Это большая уязвимость. Прочитайте эту ссылку для дополнительной информации: docs.microsoft.com/en-us/sql/relational-databases/security/…

— QMaster

С такими ответами неудивительно, что существует так много плохо защищенных веб-сайтов и баз данных. Черт возьми.

— Дэйв