Использование роли приложения для установки схемы по умолчанию - команды неожиданно используют dbo - PullRequest
Новая
       6

Использование роли приложения для установки схемы по умолчанию - команды неожиданно используют dbo

0 голосов
/ 04 мая 2018

Я пытаюсь использовать роль приложения со специальной схемой по умолчанию, чтобы упростить использование команд SQL без обозначений схемы, то есть неквалифицированных имен. Мне нужно создать и работать с 4+ полными наборами таблиц + просмотры + и т. Д. (каждый 50-100 объектов), которые все должны работать исключительно в пределах своей собственной схемы.

Чтобы проверить это, я создал роль приложения с подходящей схемой по умолчанию. Затем я использую sp_setapprole, чтобы прикрепить эту роль, и sp_unsetapprole, чтобы вернуться к моей предыдущей роли. Кажется, это работает, так как SCHEMA_NAME () возвращает ожидаемое имя схемы (и 'dbo' до 'set' и после 'unset').

Находясь в моем утверждении, я пытаюсь удалить и создать таблицу, а затем вставить запись в созданную таблицу. Удаление / создание работает нормально, но вставка завершается неудачно, так как она пытается вставить запись в таблицу с аналогичным именем в схеме 'dbo' (на что ей не было дано разрешение).

Почему моя (целенаправленно) неквалифицированная ссылка на таблицу внезапно возвращается к 'dbo', хотя моя стандартная схема по умолчанию - другая?

Также происходит сбой, когда я делаю 'select', который снова по умолчанию равен 'dbo'.

Я предоставил все возможные разрешения для моего утверждения назначенной схемы и только SELECT для dbo.

Любая помощь приветствуется.

Приветствия

Lars

1 Ответ

0 голосов
/ 04 мая 2018

Это сложно, потому что разрешение объекта основано на схеме по умолчанию, активной при анализе пакета. Таким образом, партия как это: 

DECLARE @cookie varbinary(8000);
exec sp_setapprole a_role,'P@ssword',  @fCreateCookie = true, @cookie = @cookie output 
--go
select * from t

Будет ссылаться на dbo.t, даже если a_role имеет другую схему по умолчанию. Если разбить его на две партии, то t разрешится до a.t.

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

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

    create role app_users
    create user a_user without login with default_schema=a
    grant select, insert, update, delete, execute on schema::a to a_user
    grant impersonate on user::a_user to app_users

    go

    execute as user='a_user'
      select * from t  --resolves to a.t
      select * from dbo.t --fails
    revert
...