|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
На одном сервере есть две БД: DB_Tab и DB_SP. В DB_Tab только таблицы. В DB_SP только хранимые процедуры, которые работают с таблицами из DB_Tab. Пользователь XXX имеет право только выполнять SP из DB_SP. При вызове любой SP из DB_Tab, выдается сообщение, о том, что XXX не является пользователем DB_Tab. Можно ли обойти это ограничение, но при этом не давать пользователю XXX права на таблицы из DB_Tab? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2001, 14:52 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
>Пользователь XXX имеет право только выполнять SP из DB_SP. >При вызове любой SP из DB_Tab, выдается сообщение, о том, что XXX не является пользователем DB_Tab. А зачем вызывать SP из DB_Tab? Вызывай "пользователем" SP из DB_SP... там все необходимые права уже есть (т.е. исполнение процедур), а то что SP будет обращаться к таблицам DB_Tab это уже для пользователя несущественно, т.к. процедура обращается к таблицам от имени ее создателя, а не пользователя (как правило это dbo). P.S. Единственное, с чем придется обойтись аккуратно в процедурах это с конструкциями типа EXEC("select * from DB_Tab..hidden_table where "+@Where_clause) - в этом случае из процедуры создается новый независимый коннект и в нем уже обращение к таблице идет от имени пользователя... а правов-то у него и нету обращаться к ней. Обойти это ограничение можно предварительно "загрузив" копию реальной таблицы во временную (#), и строить строку для EXEC()-а уже к этой временной таблице ( select * into #copy_of_hidden_table from DB_Tab..hidden_table EXEC("select * from #copy_of_hidden_table where "+@Where_clause) ), к этим "гадостям" права есть у всех. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2001, 15:15 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
Ищзвините, ошибся: При вызове любой SP из !!! DB_SP !!!, выдается сообщение, о том, что XXX не является пользователем DB_Tab. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2001, 15:21 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
Дык включи его туда. Только прав никаких не давай. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2001, 20:30 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
Всем большое спасибо, но процедуры все равно не выполняются пока не дашь пользователю XXX всех необходимых прав на наблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.02.2001, 10:46 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
Если я все правильно понял, то проблема скорее всего кроется в том, что, базы dbtab и dbsp имеют разных владельцев. Если объекты (таблица и процедура) имеют одного владельца то проверяется только права на верхнем уровне (только на выполнение процедуры). Если владельцы - разные, то проверяются права на всех уровнях (и в процедуре и в таблице). Отсюда выход: пусть владелец DBTAB - user1, владелец DBSP - user2. Нужно войти в базу DBTAB, добавить в нее пользователя user2(если он не является еще ее пользователем DBTAB). Поменять владельца таблицы с помощью sp_changeobjectowner mytabl, user2. Теперь все будет работать так как Вы хотите. При этом:1) все пользователи кроме user2 должны будут обращаться к mytabl как user2.mytabl, (это общее замечание, не имющее отношения к данной задаче, т.к. все будут обращаться к Mytabl через Sp). Замечание2: Все члены роли sysadmin понимаются как dbo. Это значит, что если у БД есть владелец user1, то объекты, созданные в ней членом роли sysadmin будут иметь владельцем dbo. Однако, dbo в разных базах разные и если теперь user3 в DBSP создаст процедуру, то хоть и у этой процедуры и у таблицы в DBTAB владелец dbo, все равно в DBTAB нужно таблице выполнить sp_changeobjectowner mytabl, user3. Замечание3: В случае, если пользователь использует NT-аутентификацию, его нужно взять в прямые скобки. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2001, 15:32 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
У меня базы dbtab и dbsp имеют одного владельца - dbo. Попробуйте сами создать две БД, одну с таблицей, другую с прцедурой. создайте логин, имеющий доступ на выполнение процедуры и проверте через QA. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2001, 16:18 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
Извините, все работает. Я давал права роли, а не пользователю. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2001, 16:49 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
НАверное я не очень хорошо объяснил Я же специально написал насчет Dbo в разных базах разные, может быть, правда, не очень внятно. Это значит, что если два разных пользователя SQL -я, создают каждый свою базу, то в обоих владельцем будет пользователь БАЗЫ Dbo. Но им в разных базах соответствуют разные пользователи СЕРВЕРА. Посмотрите в Enterpise Manager - там User-ах базы стоит Name и Login Nаme. Так вот, надо чтобы соответствовли Login Name. Наиболее простой способ (я кстати забыл про это сказать), поменять владельца всей базы. Но иногда этого делать очень не хотся, поэтому я и описал более тонкий путь - поменять владельца только на конкретный объект. Надо посмотреть владельца объекта (если он был создан владельцем БД или сисадмном не был изменен, то это Dbo) - это имя пользователя БАЗЫ и сопоставить с пользователем СЕРВЕРА. Эти владельцы (логины сервера) у процедур и таблиц должны совпадать... Единственный геморрой - когда сисадмин создает таблицу или Sp в базе, которую создал не он. При этом эта таблица или sp будет иметь владельцем dbo т.е. соответствовать логину сервера, соответствующего dbo этой базы. Поэтому после создания нужно принудительно поменять владельца объекта. Если пользователь, создающий объект - не сисадмин (он должен иметь права на создания таблиц или Sp соответственно), то владельцем нового объекта он станет автоматически. Я специально создал две базы, даже больше, с разными владельцами - членам sysadmin и нет и прогонял все тесты. Все работает как надо. Может я излагаю не очень хорошо, но уж как могу... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2001, 10:32 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
О, заработала таки? Так все же дело в этом или нет? Не очень понял насчет предоставления прав роли. Ведь в независимости от того, имеет юзер право на создание таблиц или Sp непосредствено, или через роль все равно владельцем объекта будет пользователь а не роль ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2001, 11:04 |
|
Доступ к таблицам через SP , если таблицы и SP находятся в разных БД,
|
|||
---|---|---|---|
#18+
При решении этой проблемы я допустил две ошибки: 1)Я давал права роли, а не пользователю. 2)Эту ошибку мне помог решить Dmitry (большое спасибо) Если SQLServer зарегистрирован в Microsoft Management Consol под SQLServer Authentication (например SA), то после создания БД, в списке пользлвателей этой БД будет Name - dbo, а Login Name - SA Дело в том, что у меня SQLServer был зарегистрирован в Microsoft Management Consol под Windows Authentication и после создания БД, в списке пользлвателей этой БД было Name - dbo, а Login Name -(пусто) После того, как я выполнил sp_changedbowner @loginame='SA', все заработало. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2001, 16:49 |
|
|
start [/forum/topic.php?fid=46&msg=32002296&tid=1827317]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
others: | 269ms |
total: | 407ms |
0 / 0 |