0

У нас есть приложение третьи стороной, которая хочет вызвать хранимую процедуру с использованием SQL 2005-стиля «схема» Синтаксис:Проблем с запуском хранимой процедуры, принадлежащей другим пользователем

Customer.InsertNewOrder 

Это дб еще на SQL 2000 , тем не менее, поэтому мы пытаемся сделать его «похожим на схему SQL 2005» и по-прежнему работать правильно (с минимальными необходимыми разрешениями). Таким образом, мы:

  1. создал пользователь с именем «Клиент»
  2. Создал ХП принадлежит этому пользователю
  3. Предоставленный веб-пользователя «выполнить» права на хранимая процедура (через роль)

Предоставление нашим пользователям прав на выполнение, как правило, всего того, что требуется для запуска обработанных dbo-процессов (например, «dbo.InsertOrder»). Обычно мы не должны предоставлять явные разрешения для базовых таблиц. Но в этом случае это не работает. Мы получаем ошибку:

INSERT permission denied on object "Order" 

Так что я делаю неправильно?

Как сообщить , что пользователю в этом случае запрещается. Это мой WebUser? Или это «выполняется как» пользователь Customer, а пользователю Клиента необходимы дополнительные разрешения? (Я попробовал предоставить дополнительные разрешения пользователю клиента (db_datareader и db_datawriter, даже попробовал db_owner), но это, похоже, не помогло. Db_owner не является вариантом в производстве. В любом случае.

Я полагаю, что могу предоставить явные разрешения INSERT в нужной таблице, но почему это необходимо в этом случае, если это не так, как для обработанного DBO proc?

EDIT:
я упростил ради этого вопроса. На самом деле, у меня есть несколько десятков хранимых процедур под двумя разными «схемами», которые вставляют, обновляют и выбирают из многих таблиц. Так надеясь не придется вручную детализировать разрешения на все, если я могу помочь ...

ответ

2

"When one user owns the source object and all target objects, the ownership chain is said to be unbroken. If different users own the target objects, the ownership chain is broken. SQL Server relies on the state of the ownership chain to determine when to check permissions.
(snip)
If the ownership chain is broken, SQL Server checks permissions on each branch of the chain owned by a different user. Only those statements where the user has the necessary permissions will be executed, and the remaining statements will get an "Insufficient Permissions" error. In this way, SQL Server allows object owners to retain control over permissions."

Цитируется из Using Ownership Chains

Чтобы применить это к текущему сценарию, когда Customer.InsertOrder Proc попытки вставить в таблицу dbo.Order, это разрушает цепочку владения, а SQL проверяет, имеет ли пользователь (в этом случае WebUser) имеет разрешение на выполнение вставки.

Таким образом, пользователю WebUser (а не клиенту) потребуется разрешение INSERT на dbo.Order (либо явно, либо через db_datawriter). При необходимости все разрешения могут быть удалены из Клиента.

+0

Явно предоставить разрешения на вставку для вашей таблицы пользователю. –

-1

Это пользователь Заказчика. Для доступа к таблице заказов требуется доступ к данным.

+0

Но пользователь Customer уже является членом роли db \ _datawriter на уровне базы данных. Разве этого недостаточно? – BradC

+0

Что произойдет, если вы ссылаетесь на таблицу заказов как dbo.Order из InsertNewOrder sp? –

+0

Не уверен.Не хочу этого делать, если мне это не нужно, так как это всего лишь одна из нескольких десятков проков (я упростил ради вопроса). Вы правы, однако, хранимый proc не использует полностью квалифицированное имя таблицы. – BradC