|
|
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
Тут обнаружил сообщение в microsoft.public.sqlserver.security: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. Пользователь <some user> может успешно вызывать direct... Я всегда считал, что DENY имеет приоритет над GRANT. А тут выходит, что нет... Или это баг? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:03:21 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
я наверное не прав буду, если скажу что процедура отработала в соответствии с правами своего создателя dbo ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:06:41 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
Это понятно, речь о том, что <some user>'у явно запрещен SELECT из таблицы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:08:12 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
Все работает совершенно правильно. У пользователя есть права на процедуру direct. Текст запроса не может быть им призвольно изменен. Соотв. подразумевается, что разработчик отвечает за то, что пользователь не увидит ничего "лишнего". Это в точности соответствует концепции назначения прав доступа через View (когда запрещен select из таблицы, но у польз. есть доступ к View, который "отсекает" некоторые строки или столбцы). Совсем другое дело, когда в процедуре есть динамически строящийся запрос (выполняемый через EXEC). В этом случае злонамеренный юзер может изменить текст запроса через параметры процедуры (потенциально... для каждого конкретного случая SQL не будет пытаться проверять), поэтому права проверяются на этапе выполнения процедуры. Как следствие, для динамических запросов всегда приходится давать права на SELECT из таблицы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:17:27 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
Код: plaintext но не запрещен для dbo ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:19:12 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
Спасибо, все ясно, что к чему. Ну а вот, к примеру, необходимо запретить <some user>'у выборки из таблицы OnlyNumbers - придется для каждой процедуры типа direct делать REVOKE/DENY EXECUTE? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:32:44 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
ну да :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:36:37 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
Мда... Мягко говоря, неудобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:39:48 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
У нас для того, чтобы не "возиться" с каждым пользователем для процедуры создается пользовательская роль, котораю имеет только право EXEC на "свою" процедуру. Тогда вместо REVOKE/DENY можно просто добавлять/удалять пользователя из роли. Ну а для более удобного менеджирования всего этого написан небольшой модуль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 14:43:23 |
|
||
|
DENY & stored procedure
|
|||
|---|---|---|---|
|
#18+
Ну, если неудобно, то используйте dynamic. :) Или проверку в теле процедуры типа: Код: plaintext 1. Но вообще лучше пермишины на таблицы не раздавать, а проверять принадежность к роли. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2002, 16:37:18 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32057990&tid=1819624]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
23ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
| others: | 206ms |
| total: | 324ms |

| 0 / 0 |
