Як дозволити виконувати збережені процедури, але не записувати?

Я хотів би створити користувача, який читає, на моєму екземплярі SQL Server 2012. Я хотів би дозволити йому право виконувати будь-яку збережену процедуру або функцію, або прямий оператор SQL, який витягує дані з усіх таблиць і представлень, але не оновлювати чи вставляти (тобто нічого не читати і нічого не писати).

Чи можу я налаштувати це, не конкретно надаючи права на кожну функцію чи збережену процедуру за назвою, а краще надати йому право виконання на будь-яку функцію чи збережену процедуру, лише позбавивши право змінювати таблиці?

Чи щось зміниться, якщо замість цього я запустя SQL Server 2008?

Пояснення та доповнення:

Якщо збережена процедура змінює дані, користувач повинен отримувати повідомлення про помилку (або забороняючи модифікацію, або повністю відмовляючи в доступу до збереженої процедури).
Якщо потенційне рішення передбачає заборону дозволів, чи можу я просто не надати певні дозволи замість відмови?
Чи може заперечення застосовуватися до всіх таблиць, представлень тощо (існуючих зараз і в майбутньому) в базі даних в одному висловлюванні?

— gt6989b
джерело

Я новачок тут, будь ласка,

— сміливо

@KrisGruttemeyer така думка - він міг її виконати, але це призведе до якоїсь помилки; в іншому випадку мені все в порядку, тому що його не дозволяють виконувати, доки мені не доведеться вказувати список списку, у якого він має привілеї

— gt6989b

У такому випадку вам потрібно прочитати про дозволи SQL Server. Існує 3 варіанти дозволів - GRANTнадати дозволи, DENYзаборонити дозволи та REVOKEвидалити GRANTабо DENY. Без GRANTабо DENYкористувач може успадкувати дозволи, скажімо, отримати доступ до збереженої процедури.

— JNK

@ gt6989b Якщо ви знаходитесь DENY DELETE, INSERT, UPDATEу базі даних чи схемі, я вважаю, що це вплине лише на таблиці та представлення даних.

— JNK

@ gt6989b - Просто зазначивши, що запропонована відповідь у цих коментарях виявилася невірною. Дивіться відповідь Пола Уайта.

— RLF

Це не так просто досягти, як можна подумати. Один із способів - створити нову визначену користувачем роль бази даних, дати всі дозволи, необхідні для цієї ролі, а потім додати користувачів до нової ролі. Це принаймні полегшує надання користувачам (або іншим визначеним користувачем ролям) цей набір дозволів у майбутньому. Наступні кроки - вдалий початок:

-- The user-defined role containing all required permissions
CREATE ROLE Readers AUTHORIZATION dbo;

-- Give read-only access to all tables,
-- views on those tables, and in-line
-- functions
ALTER ROLE db_datareader ADD MEMBER Readers;

-- Example: add a user (Bob) to the role
ALTER ROLE Readers ADD MEMBER Bob;

Після цього у Боб будуть широкі права доступу для читання в базі даних. Він зможе читати з усіх таблиць, перегляди цих таблиць та функції в режимі рядка. Однак він не зможе виконувати жодних процедур або використовувати не вбудовані функції.

Вам потрібно буде надати конкретні дозволи на роль читачів для безпечних функцій та процедур, до яких бажаєте мати читачі. Можливо, ви можете зробити кроки для полегшення цього процесу (наприклад, об'єднання об’єктів у схему та надання дозволу на виконання схеми замість окремих об'єктів), але тут є занадто багато деталей, які слід висвітлити.

Слід пам’ятати, що відсутність привілеїв на зміну даних не завадить читачеві змінювати дані через збережену процедуру, на яку вона отримала дозвіл на виконання, якщо процедура та об'єкт, що змінюється, мають спільного власника. У цьому випадку явний заперечення також не буде дотримано. Ця функція відома як Ланцюжок власності .

— Пол Білий 9
джерело