Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 3 вперед Ctrl→ все |
ttt_user
Guest |
revoke connect to ttt grant connect to guest execute as user = 'ttt' select USER_NAME() revert Почему вернулось ttt (и все права как у ttt), а не guest, ведь доступ осуществлён через права guest? В общем случае права guest не прибавляются (например, добавление guest прав на select таблицы не позволяет ttt прочитать её содержимое). |
27 янв 15, 14:35 [17176760] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
А что должна была вернуть USER_NAME(), после execute as user = 'ttt' ? |
||
27 янв 15, 14:38 [17176797] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
А с чего права guest-а должно кому то прибавляться ? Permissions granted to the guest user are inherited by users who do not have a user account in the database. |
||
27 янв 15, 14:41 [17176828] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
Я ждал "The server principal is not able to access the database under the current security context", так как у ttt нет прав доступа к БД. Ну раз уж USER_NAME() стала выполняться за счёт прав guest, то по крайней мере guest, ну уж никак не ttt с отсутствующими правами доступа. |
27 янв 15, 14:42 [17176839] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
А где в вашем скрипте происходит connect к базе ? |
||
27 янв 15, 14:45 [17176868] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
execute as user = 'ttt' требует привилегии "connect". Если прав "connect" нет ни у ttt, ни у guest, то ошибка "The server principal is not able to access the database under the current security context". То есть привилегия "connect" у guest добавилась к привилегиям ttt. Другие привилегии guest не добавляются к привилегиям ttt. Было бы логично одинаковое поведение для всех привилегий. То есть не пускать ttt при наличии права "connect" у guest. Аналогичное поведение и из Management Studio. Connect к базе проходит при логине, к которому относится ttt, когда есть право "connect" у guest, но нет у ttt. И USER_NAME() возвращает ttt. |
27 янв 15, 14:59 [17177007] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
куда это доступ под guest-ом осуществлен? вы вообще в базу проникли под dbo, являясь админом. а потом уже отперсонэйтили ttt в контексте базы. для чистоты эксперимента надо было снаружи базы делать execute as login = 'ttt'; use db0 select USER_NAME(); потом в базу заходить. но и все равно USER_NAME() будет ttt показывать, эта ф-ция к коннекту отношения не имеет: When USER_NAME is called without specifying an id after an EXECUTE AS statement, USER_NAME returns the name of the impersonated user. USER_NAME (Transact-SQL) impersonated user = ttt удалите вообще юзера ttt из базы, тогда получите guest. отберите и у guest connect, получите Msg 916, Level 14, State 1, Line 1 The server principal "ttt" is not able to access the database "db0" under the current security context. |
||
27 янв 15, 15:01 [17177033] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Для того, чтобы НЕ пускать, должно быть явно указано НЕ пускать. А revoke connect to ttt - это не deny connect to ttt |
||
27 янв 15, 15:01 [17177038] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
ссылку на документацию предъявите, где требует. по моей ссылке постом выше такого нет |
||
27 янв 15, 15:04 [17177078] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
извиняюсь, моя ссылка на USER_NAME, и ответ относился к USER_NAME, а не к execute as |
||||
27 янв 15, 15:08 [17177127] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
Так я не хочу не пускать. Я хочу, чтобы пускали, когда есть права (дали права ttt - пустили, включили ttt в роль, имеющую права - пустили). В описанной ситуации у ttt нет прав (нет оснований, чтобы права guest к нему добавлялись). А его пускают, так как у не имеющего к нему отношения guest есть такие права. |
||
27 янв 15, 15:13 [17177200] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
И откуда сервер это узнает, что вы не хотите ? Вы же не сказали, что "вот этого НЕЛЬЗЯ пускать"
А guest - это не права ? А доступ через группы/роли - это тоже не права ?
Поймите уже - отсутствие явных прав не есть тоже, что запрет Прочитайте про разницу между revoke и deny |
||||||
27 янв 15, 15:18 [17177254] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
Я понимаю, что есть явные и неявные права. Например, доступ через группы/роли - это неявные права. Вот я и хочу понять, откуда у ttt неявные права на доступ к базе. Если guest - это права, то ВСЕ права guest должны добавляться к ttt. Однако, например, право guest на SELECT не добавляется к правам ttt. Тогда получается, что конкретно право guest на connect - это неявное право для всех, а любые другие права guest - только для не имеющих логина, для которых USER_NAME вернёт guest. |
||
27 янв 15, 15:29 [17177360] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Ну так grant connect to guest
Где репродакшен ? |
||||
27 янв 15, 15:30 [17177380] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
if exists(select * from sys.objects where object_id = OBJECT_ID('Test')) drop table Test go create table Test(ID int NOT NULL) go insert into Test(ID) values (1) grant select on Test to guest; execute as user = 'ttt' select * from Test -- The SELECT permission was denied revert execute as user = 'guest' select * from Test -- Возвращена таблица revert |
||
27 янв 15, 15:44 [17177512] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
И это вы называете "право guest на SELECT не добавляется к правам ttt." ? |
||
27 янв 15, 15:48 [17177557] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
В чистом эксперименте всё то же самое, что и в моём. При отсутствии прав и у ttt, и у guest "The server principal is not able to access the database". Если есть права у guest, но нет у ttt, то пускают с правами ttt. |
||
27 янв 15, 15:49 [17177564] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
Там был и второй похожий фрагмент кода:
|
||||||
27 янв 15, 15:52 [17177584] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Еще раз guest не добавляет кому-то прав. И не отнимает. Еще раз цитата Permissions granted to the guest user are inherited by users who do not have a user account in the database. Переводится это как Права назначенные пользователю guest наследуются теми пользователями, которые не имеют учетной записи в базе Ваш ttt имеет user account в базе или не имеет ? |
||||
27 янв 15, 15:55 [17177619] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
Пользователь сервера имеет соответствующего пользователя в базе. Обсуждаемое право "connect" на базу - это право уровня пользователя базы. Права назначенные пользователю guest наследуются теми пользователями, которые не имеют учетной записи в базе, то есть не наследуются пользователем ttt. Для SELECT так и происходит. Для Connect право унаследовалось, несмотря на то, что пользователь имеет учётную запись в базе. |
||
27 янв 15, 16:15 [17177797] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Откуда connect то уноследовался ? Вы уже присоеденены к базе при выполнении execute as user Permissions To specify EXECUTE AS on a login, the caller must have IMPERSONATE permissions on the specified login name. To specify EXECUTE AS on a database user, the caller must have IMPERSONATE permissions on the specified user name. |
||
27 янв 15, 16:22 [17177870] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
нет, ну ТС уже исправился и зашел в базу чисто, из мастера, сделав там execute as login. и действительно теперь неплохо бы считать, что в базу он попал именно как guest. можно еще оправдать user_name, показывающий соответствующего юзера для login. но не катит проверка прав. если сейчас выполнить select * from sys.fn_my_permissions(null, 'database') то никакого connect-а нет. а на самом деле есть, т.к. он прошел как guest. можно не имперсонэйтить, а зайти действительно под этим логином. в базу он попадет -- пройдет как guest. а права получит юзера ttt. значит, права сложились, но выборочно: коннект guest-а ему перепал, а остальное нет. неконсистентно! |
||||
27 янв 15, 16:31 [17177942] Ответить | Цитировать Сообщить модератору |
ttt_user
Guest |
execute as не выполнится, если нет прав на connect к текущей базы ни у ttt, ни у guest Выполняется: revoke connect to ttt grant connect to guest execute as user = 'ttt' select USER_NAME() revert "The server principal is not able to access the database under the current security context": revoke connect to ttt revoke connect to guest execute as user = 'ttt' select USER_NAME() revert |
||||
27 янв 15, 16:33 [17177958] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Что значит "чисто" ? Если он зашел в базу уже как guest, то зачем ему еще выполнять execute as user = 'guest' ? |
||
27 янв 15, 16:33 [17177960] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
А как тогда выполнятеся revoke connect to ttt, если уже нет прав на connect к текущей базы у ttt ? Или вы сначала дали права на connect. Потом соединились с базой. А потом в этом соединении ждете, что после выполнения revoke connect to ttt вам нужно будет заново устанавливать соединение с базой ? |
||
27 янв 15, 16:37 [17177991] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 3 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |