Предоставить доступ к INFORMATION_SCHEMA

Question

У нас есть утилита, которая делает магию SQL, отражая определение для некоторых представлений и хранимых процедур.Чтобы это работало, код должен иметь доступ к различным полям в таблицах INFORMATION_SCHEMA.ROUTINES, INFORMATION_SCHEMA.VIEWS и т. Д.

Итак, мы написали курсор, который применяет

GRANT VIEW DEFINITION on ' + @Name + ' TO tenant'

, где арендаторроль, под которой исполняется код, а @Name является переменной курсора для имени процесса.Это работает.

Но тогда кто-то неизбежно отбросит / заново создаст процесс, тем самым удалив доступ к определению этого процесса, что приведет к сбою магической утилиты.

Так что лучше всего сказать«Весь код, выполняемый под ролью« арендатора », имеет полный доступ на чтение ко всем таблицам INFORMATION_SCHEMA?»

Редактировать:

Я попытался GRANT VIEW ANY DEFINITION TO tenant, и он вызываетследующая ошибка:

Невозможно найти логин 'арендатор', поскольку он не существует или у вас нет разрешения.

Это потому, что арендатор является ролью, а непользователь, или я просто действительно не имею разрешения?Я вошел как sa.

Answer 1

Я не хочу отвечать на свой вопрос, но, похоже, это работает:

GRANT VIEW DEFINITION TO tenant

Это работает в области базы данных.

GRANT VIEW ANY DEFINITION TO tenant

должно работать в области сервера, но я получаю: «Не могу найти логин« арендатор », потому что он не существует или у вас нет разрешения».Это потому, что «арендатор» - это роль, а не пользователь?

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

Answer 2

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

If Exists(...)
 Drop Proc Foo

Create Proc Foo
As


GO

GRANT VIEW DEFINITION on Foo TO tenant
GO

Answer 3

начинайте использовать ALTER PROCEDURE ...., если это не начальный фактический СОЗДАНИЕ процедуры, это сохранит права доступа без изменений.

Команда CREATE используется только при первом создании процедуры, а затем всегда ALTER.В результате, нет необходимости отбрасывать его (и терять все разрешения). СОЗДАЙТЕ его снова каждый раз, когда вы вносите изменения.

РЕДАКТИРОВАТЬ
вот способ, которым выВы можете изменить свою хранимую процедуру (работает также с VIEWS), так что вы всегда можете использовать ALTER:

BEGIN TRY
    --create a dummy procedure if it doesn't already exist
    EXEC ('CREATE Procedure YourProcedure AS SELECT 1/0')
END TRY BEGIN CATCH END CATCH --ignore the error if it already exits
GO

ALTER Procedure YourProcedure --it will always exist, because of the above code
AS
SELECT 'Hello World!'
GO

, при этом вы просто используете ALTER и никогда IF EXITS ... DROP затем CREATEрисунок.