Версия для печати

На главную страницу

Изменение контекста выполнения в SQL Server 2005

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

В SQL Server 2005 имеется предложение EXECUTE AS, которое позволяет Вам переключать контекст выполнения для пакетов и процедур с другими разрешениями, чем те, которыми обладает лицо, вызывающее процедуру или пакет.

Цепочки владения

Прежде чем я перейду к тому, как изменить контекст выполнения в SQL Server 2005, важно разобраться, как работают цепочки владения.

Когда пользователь выполняет хранимую процедуру (а мы предполагаем, что пользователь имеет разрешения на выполнение хранимой процедуры), SQL Server проверяет владельца (Schema) процедуры и сравнивает его с владельцем любых объектов, которые доступы через процедуру. Если процедура и какие-нибудь вызываемые в ней объекты имеют того же самого владельца, разрешения на объект (ты), на которые имеются ссылки, не проверяются. Так, если пользователю Тиму дают разрешения на выполнение процедуры с именем usp_ProcedureChain принадлежащую dbo, то пока dbo владеет любыми другими процедурами, которые вызывает usp_ProcedureChain, никакой ошибки не будет возникать при выполнении Тимом этой процедуры.

Переключение контекста

В SQL Server 2000 Вы могли использовать команду SETUSER, чтобы представиться в контексте пользователя для учетной записи SQL User Account. К сожалению, эта команда могла использоваться только sysadmin или db_owner и не могла использоваться для учетных записей Windows.

В SQL Server 2005 вместо SETUSER для изменения контекста выполнения хранимой процедуры, триггера, пакета или функции под конкретным именем пользователя или логином в определении кода можно использовать предложение EXECUTE AS. Когда контекст изменен на другого пользователя или логин, SQL Server проверит разрешения для этого логина или пользователя. Чтобы задать предложение EXECUTE AS, когда вы создаете или модифицируете процедуру или функцию, необходимо иметь разрешения IMPERSONATE на данный объект, а также разрешения создавать объекты.

Пример

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

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

REVERT

GO

Семь операторов в листинге A - операторы очистки, которые проверяют наличие объектов, которые я буду использовать позже; и, если последние существуют, то я удаляю их.

Листинг A

IF OBJECT_ID('usp_InsertMyTable','P')>0
    DROP PROCEDURE usp_InsertMyTable

GO

IF OBJECT_ID('TableOwnerSchema.MyTable','U')>0
    DROP TABLE TableOwnerSchema.MyTable

GO

IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'TableOwnerSchema')
    DROP SCHEMA [TableOwnerSchema]

IF EXISTS (SELECT * FROM sys.database_principals WHERE name = N'BaseUser')
    DROP USER BaseUser

IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N'BaseUser')
    DROP LOGIN BaseUser

IF EXISTS (SELECT * FROM sys.database_principals WHERE name = N'TableOwner')
    DROP USER TableOwner

IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N'TableOwner')
    DROP LOGIN TableOwner

Следующий скрипт создает два серверных логина и две учетные записи пользователя базы данных для регистрации. Обратите внимание на операторы CHECK_EXPIRATION и CHECK_POLICY, которые впервые появились в SQL Server 2005. Эти операторы сообщают SQL Server не предписывать политику истечения пароля этой пользовательской учетной записи, и не проверять для этой учетной записи никакие типы политики пароля. Это очень полезные опции для предписания политики безопасности для учетных записей SQL.

CREATE LOGIN [BaseUser] WITH PASSWORD=N'baseuser',
DEFAULT_DATABASE=[TRS],
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

CREATE USER [BaseUser] FOR LOGIN [BaseUser]

GO

CREATE LOGIN [TableOwner] WITH PASSWORD=N'tableowner',
DEFAULT_DATABASE=[TRS],
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

CREATE USER TableOwner FOR LOGIN TableOwner

GO

В SQL Server 2005 схема уже не трактуется как пользователь базы данных; это - совершенно отличное пространство имен, служащее контейнером объектов. Разделение пользователя и схемы - хорошее дело, поскольку это делает владение объектами передаваемым и намного более просто управляемым по сравнению с SQL Server 2000. Следующий оператор создает схему, которую я буду использовать для примера:

CREATE SCHEMA [TableOwnerSchema] AUTHORIZATION [TableOwner]

GO

Чтобы использовать логины, разрешу их:

ALTER LOGIN [TableOwner] ENABLE

ALTER LOGIN [BaseUser] ENABLE

GO

GRANT CREATE TABLE TO TableOwner

GO

Сначала я использую команду EXECUTE AS. Этим я устанавливаю текущий контекст выполнения на контекст TableOwner. После выполнения этой команды все оценки разрешений будут выполняться для этого TableOwner; предыдущие привилегии sysadmin не будут применяться.

EXECUTE AS USER = 'TableOwner'

GO

Выполните следующий оператор, чтобы увидеть, что текущий контекст выполнения является контекстом TableOwner:

SELECT SESSION_USER

GO

Следующий скрипт создает таблицу MyTable в схеме TableOwnerSchema. TableOwner имеет разрешение выполнить этот оператор, поскольку ранее я предоставил этому пользователю разрешения CREATE TABLE.

CREATE TABLE TableOwnerSchema.MyTable
(
    Field1 INT
)

GO

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

REVERT

GO

SELECT SESSION_USER

GO

Теперь я выполню оператор select для выборки из нашей новой таблицы, чтобы удостовериться, что она существует:

SELECT * FROM TableOwnerSchema.MyTable

GO

Следующий скрипт создает процедуру, которая будет выполнять вставку в новую таблицу TableOwnerSchema.MyTable. Обратите внимание, что я использую оператор WITH EXECUTE AS 'TableOwner' в определении процедуры. Это означает, что когда процедура выполняется, она будет всегда выполняться в контексте TableOwner.

CREATE PROCEDURE usp_InsertMyTable

WITH EXECUTE AS 'TableOwner'

AS
BEGIN
INSERT INTO TableOwnerSchema.MyTable(Field1)VALUES(8)

END

GO

Я могу предоставить разрешения на выполнение этой хранимой процедуры учетной записи пользователя. Здесь я использую предварительно созданную учетную запись с именем BaseUser.

EXECUTE AS USER = 'BaseUser'

GO

EXEC usp_InsertMyTable

GO

Мне удалось вставить запись в таблицу TableSchema.MyTable, потому что контекст выполнения TableOwner в процедуре позволяет мне делать это. BaseOwner не имеет явных разрешений на вставку в эту таблицу, в результате любая его попытка сделать это приведет к ошибке. Для иллюстрации сказанного выполните следующий скрипт, который изменит нашу процедуру так, чтобы она исполнялась в контексте выполнения того, кто вызывает процедуру.

REVERT

GO

ALTER PROCEDURE usp_InsertMyTable

AS
BEGIN
INSERT INTO TableOwnerSchema.MyTable(Field1)VALUES(8)

END

GO

EXECUTE AS USER = 'BaseUser'

GO

EXEC usp_InsertMyTable

GO

REVERT

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

12-02-2007

На главную страницу

  Версия для печати