Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 У кого-то заработал cross db вызова через db owner + authenticate?  [new]
Ольга Никитина
Guest
Вот тут описывается вариант, где овнеру одной базы создается юзер в другой базе, где ему дается authenticate. Первой базе ставится trustworthy и все начинает свистеть как надо. Шиш! Не получается. Кто кинет работающее репро?

Варик с сертификатом пашет.
6 май 15, 10:05    [17605734]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
o-o
Guest
да конечно работает.
у вас какой версии сервер?
не думаю, что что-то поменялось, у меня на 2008 R2 все отлично, сейчас накатаю репро.
там вроде и делать особо нечего...
6 май 15, 10:09    [17605749]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
Ольга Никитина
Guest
o-o
у вас какой версии сервер?


автор
Microsoft SQL Server 2014 - 12.0.2480.0 (X64)
Jan 28 2015 18:53:20
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)
6 май 15, 10:13    [17605761]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
o-o
Guest
Microsoft SQL Server 2014 - 12.0.2480.0 (Intel X86) Jan 28 2015 19:03:03 Copyright (c) Microsoft Corporation Express Edition on Windows NT 6.1 <X86> (Build 7601: Service Pack 1)
create database db1_o;
create database db2_o;
create login oo with password = '*****', check_policy = off;
go

use db2_o;
create user oo from login oo;
create table dbo.t(id int);
go
grant select on dbo.t to oo; 
go

use db1_o;
create user oo from login oo;
go

create proc dbo.usp_test
with execute as 'oo' 
as
select *
from db2_o.dbo.t;
go

create user test_user without login;
go

grant execute on dbo.usp_test to test_user;
go

execute as user = 'test_user';
exec dbo.usp_test;
--Msg 916, Level 14, State 1, Procedure usp_test, Line 5
--The server principal "oo" is not able to access the database "db2_o" under the current security context.

revert;
alter database db1_o set trustworthy on;

execute as user = 'test_user';
exec dbo.usp_test;
go
--
--id

revert;
6 май 15, 10:33    [17605865]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
Ольга Никитина
Guest
o-o,

спасибо, а я надеялась, что будет работать (если судить по доке) в таком виде:

use master;
go

drop database dbA;
drop database dbB;
go

drop login dbA_owner_login;
drop login test_login;
go

create database dbA;
create database dbB;
go

create login dbA_owner_login with password = 'P@ssw0rd'
go

alter authorization on database::dbA to dbA_owner_login;
go

use dbB;
go

create user dbA_owner_user from login dbA_owner_login;
go

grant authenticate to dbA_owner_user;
go

use dbA;
go

create user exec_user without login;
go


create procedure p with execute as 'exec_user' as
begin
	select * from sys.login_token;
	select * from sys.user_token;

	select * from dbB.dbo.t;
end;
go

use dbB;
go

create table t(data nvarchar(100));
go

insert into t(data) values ('hello from dbB');
go

grant select on dbo.t to dbA_owner_user;
go


use master;
go

alter database dbA set trustworthy on;
go

create login test_login with password = 'P@ssw0rd'
go

use dbA;
go

create user test_user from login test_login;
go

grant execute on dbo.p to test_user;
go

use dbA;
go

execute as login = 'test_login'

select * from sys.login_token;
select * from sys.user_token;

exec dbo.p;

revert;



автор
Msg 916, Level 14, State 1, Procedure p, Line 87
The server principal "S-1-9-3-809277290-1280721743-24120448-2264949717" is not able to access the database "dbB" under the current security context.


Вроде и аутентификатор прицепляется к контексту и для него есть юзер в базе B, и trustworthy для A включен. А не выходит чета.
6 май 15, 10:49    [17605987]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
o-o
Guest
Ольга Никитина,

я вашу идею не совсем понимаю,
у вас же нет юзера exec_user во второй базе.

тот метод зачем нужен:
если у меня есть логин (из него будем делать юзеров в обеих базах),
то внутри базы он все равно всего лишь юзер, не логин.
и когда вы пишете в процедуре with execute as 'exec_user'
вы исполняете процедуру от имени этого юзера (не логина!!!)

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

когда вы на базе включаете trustworthy on,
вторая база начинает "верить" той, что с trustworthy on,
если конечно овнер базы имеет authenticate.
типа овнер поручился, что тот юзер exec_user, он же логин exec_user,
он же юзер exec_user во второй базе.

смотрите на ошибку, когда у меня на базе не включено trustworthy:
The server principal "oo" is not able to access the database "db2_o" under the current security context.
т.е. он сообразил, что то мое оо вообще-то логин,
но на самом деле в процедуре он юзер, а у юзера песочница = база.
чтобы пробросить его в другую базу и нужен trustworty + authenticator.

вся красота в том, что если у овнера базы есть права сисадмина,
то заодно есть и authenticate server.
т.е. любой юзер базы сможет вылезти из базы с правами на сервер.
поэтому достаточно завести в базе с trustworthy юзера, у к-ого логин -- сисадмин,
т.е. сгодится произвольный сисадмин кроме sa, и у него будут админские права на сервер.

поэтому нехорошо включать на базе trustworthy.
db_owner спокойно создает себе такого юзера и обретает права на сервер, ведь у db_owner-а есть и create user, и impersonate
6 май 15, 15:16    [17607865]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
o-o
Guest
лучше это же в оригинале читать,
а то у меня такой "вольный" перевод, что лучше было с ним не лезть.
приведу нужное из вашей же статьи:

when impersonating a principal by using the EXECUTE AS USER statement,
or within a database-scoped module by using the EXECUTE AS clause,
the scope of impersonation is restricted to the database by default.


It is possible that the owner of a database, while having full permissions within that database, does not have any permissions outside the scope of the database. Therefore, SQL Server does not allow the database owner to impersonate, or grant someone else the ability to impersonate, another user in order to access resources beyond the scope of the current permissions of the database owner.

For example, consider two databases in a hosting environment and each database belongs to a separate owning entity. Database 1 is owned by Bob and Database 2 is owned by Fred. Neither Bob nor Fred wants the other to access resources within their respective databases. As the owner of Database 1, Bob can create a user for Fred in his database and because he has full permissions within Database 1, Bob can also impersonate user Fred. However, because of the security restrictions imposed by SQL Server, Bob cannot access Fred’s database under the impersonated context. Without these default restrictions in place, Bob would be able to access Fred’s data without his knowledge. This is why the scope of database-level impersonations is bounded by the database by default.

However, in certain scenarios it may be useful to selectively extend the scope of impersonation beyond the database.

In order to extend the scope of an impersonation from within a database to a target scope, such as another database or the instance of SQL Server, the following conditions must be met.

The authenticator must be trusted in the target scope.

The source database has to be marked as trustworthy.

т.е. овнер базы тут нужен не для того, чтобы его права "добавлялись" исполнителю процедуры,
это не как с сертификатами, овнер базы должен просто выступить как authenticator, чтобы "расширить контекст имперсонэйта",
для этого и нужен ему authenticate
6 май 15, 16:03    [17608183]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
Ольга Никитина
Guest
o-o, Большое вам спасибо. Теперь поняла.

Еще голову себе поломала, не знаю как трактовать

sys.user_token колонку

usages

GRANT OR DENY;
DENY ONLY;
AUTHENTICATOR.


Мне кажется это ключ к полному пониманию происходящего. Не подскажете где подробное почитать?
6 май 15, 18:45    [17609330]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
o-o
Guest
Ольга Никитина,
Из дома поищу, но в свое время мне не попалось ничего. Методом тыка установлено, когда там grant or deny, права того принципала к правам данного добавляются, а если deny only, то нет.
Надо попросить invm, наверняка он знает, где это расписано
6 май 15, 19:10    [17609427]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
Ольга Никитина
Guest
o-o
Ольга Никитина,
Из дома поищу, но в свое время мне не попалось ничего. Методом тыка установлено, когда там grant or deny, права того принципала к правам данного добавляются, а если deny only, то нет.
Надо попросить invm, наверняка он знает, где это расписано


А как его попросить?

Вот нагуглила. Но там не описуют, как потом комбинируются права каждого identity для вычисления active permissions и как колонка usage в этом участвует.

[url=]http://sqlity.net/en/1778/secret-security-token-sql-server-determines-active-permissions/[/url]
6 май 15, 19:33    [17609524]     Ответить | Цитировать Сообщить модератору
 Re: У кого-то заработал cross db вызова через db owner + authenticate?  [new]
invm
Member

Откуда: Москва
Сообщений: 9824
Ольга Никитина
А как его попросить?
Не надо его просить, он сам придет :)
По поводу столбца usage мне сказать нечего - не интересовался.

Ольга Никитина
Кто кинет работающее репро?
+ Репро
use master;
go

create login l1 with password = '', check_policy = off;
create login l2 with password = '', check_policy = off;
go

create database DB_01;
create database DB_02;
alter authorization on database::DB_02 to l1;
alter database DB_02 set trustworthy on;
go

use DB_01;
go

create user l1 for login l1;
create user l2 for login l2;
go

create procedure dbo.p1
as
begin
 set nocount on;

 select * from sys.user_token;
end;
go

grant execute on dbo.p1 to l2;
grant authenticate to l1;
go

use DB_02;
go

create user l2 for login l2;
go

execute as user = 'l2';
go

exec DB_01.dbo.p1;
go

revert;
go

use master;
go

alter database DB_01 set single_user with rollback immediate;
alter database DB_02 set single_user with rollback immediate;

drop database DB_01;
drop database DB_02;
go

drop login l1;
drop login l2;
go

Соответственно, если убрать
grant authenticate to l1;
работать перестанет.
6 май 15, 21:47    [17609933]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить