Какие еще разрешения требуются пользователю для выполнения системной хранимой процедуры таблицы master?

Потерял день, но так и не понял, почему хранимая процедура заявляет, что у пользователя нет разрешений на выполнение этого действия.
Теперь по порядку.
Написал простенькую процедуру. Создал роль. У роли в защищаемых объектах разрешение только на соединение с сервером. Создал имя входа. Имя входа принадлежит к созданной роли и естественно к public. Имя входа и есть имя пользователя базы данных. У пользователя в защищаемых объектах на созданную процедуру на выполнение есть разрешение.
Вызываю процедуру из программы - все ОК. Возвращает то, что надо. Однако стоит добавить такие строки:

как тут-же сервер меня пинает с сообщением о отсутствии разрешений. Но я просмотрел права на представление - они в public. Добавил разрешение на базу master - поровну. Добавил разрешение на выборку из master - по фиг. Блин, так какие разрешения нужны еще для того, чтобы выполнять системные хранимые процедуры из базы master?
Совершенно не желается использовать встроенные схемы. Хочу дать доступ только к функциям и все.
Заранее спасибо!

PS: Подозреваю, что дело может быть в доступе к session_id=@@SPID но куда рыть то? От пользователя sa - все выполняется как надо.

Добавлено через 21 минуту
Проверил - @@SPID ни при чем. То есть все же дело в выборке из таблицы master посредством представления
master.sys.dm_exec_connections

Добавлено через 31 минуту
Неправильно выразился - дело либо в отсутствии прав (а к этому времени я уже их назначил на выборку и все равно пофиг) на представление master.sys.dm_exec_connections, ну либо требуются еще какие-то права... Какие, черт бы их побрал...

0

Разрешения бывают не только уровня БД, но и уровня сервера.

Разрешения, необходимые для использования того или иного системного представления или процедуры перечислены в документации по этому представлению или продедуры.
В данном конкретном случае требуется view server state. Т.к. это разрешение уровня сервера, его нельзя выдать пользователю или роли в БД.

1

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

Добавлено через 16 минут
И да, я там накосячил в имени топика. Не таблицы master а базы данных master. Ну простите великодушно... Если кто может - исправьте плиз.

0

Сообщение от RafStudio В общем пришлось имени входа назначить роль сервера serveradmin, точнее помимо созданной роли добавить вышесказанную. Внешне - особо ничего не изменилось. Как не было у пользователя особых прав, так и нет. Но насколько это безопасно - Бог его знает.

Документацию принципиально не хотите читать?

Сообщение от Документация Члены фиксированной серверной роли serveradmin могут изменять параметры конфигурации на уровне сервера, а также выключать сервер.

Вот и решайте насколько это безопасно...

0

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

Добавлено через 2 минуты
Ё-маё! Тут как на зло еще и ЧМ мира по футболу: Россия - Бельгия...

Добавлено через 9 минут
Да и вообще злит - есть вроде подходящая роль public однако рулить ей на уровне той же самой базы данных - никак. С виду - бред. Ну как-так?!!

0

Сообщение от RafStudio Однако - я так и не нашел ничего путного в разрешениях на уровне сервера для ролей.

О каких ролях идет речь? О ролях уровня БД или уровня сервера? Если о ролях в БД, то да, назначить им серверные роли невозможно. А вот серверной роли public вполне можно:Опять же, с точки зрения безопасности, это не лучшее решение.
Например, если используется аутентификация Windows, можно создать Windows-группу, зарегистрировать ее как имя входа в SQL Server и дать ей нужное разрешение. И рулить уже через членство Windows-пользователей в этой группе.
Есть еще несколько способов, где вообще не требуется манипулировать ролями...

1

Спасибо огромное за уделенное время! В принципе должен был понять сразу, что серверной ролью можно крутить только на уровне сервера, а не так как мне видится. По поводу аутентификации Windows и я говорю нашему сисадмину. Но он пока только отмахивается - борется с руководством за покупку WinServer с надеждой поднять ActivDirectory и только тогда подумать. А мне необходимо уже сейчас!
Впрочем - по мне, так предложенное Вами решение уже выход!
Еще раз спасибо!

Добавлено через 2 часа 10 минут

Сообщение от invm Есть еще несколько способов, где вообще не требуется манипулировать ролями...

- вот эта фраза очень любопытна и заинтересовала. Если нет возможности описать детально, согласен на ссылку!

0

1. Если SQL Server 2012 или выше, то есть возможность создать пользовательскую роль уровня сервера.
2. Подписать процедуру - Подписание модулей (компонент Database Engine)
3. В процедуре установить контекст выполнения от имени dbo с помощью предложения execute as. В этом случае владелец БД должен быть sa или другой член роли sysadmin. Так же необходимо установить для БД опцию trustworthy в on.

1

Это вне всякого - стоит изучить и рассмотреть!
Спасибо!

0