SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Firebird, HQbird, InterBase » mon$attachments (изменение поведения от 3 к 4 к 5)
mon$attachments [сообщение #5811] Thu, 12 December 2024 09:27 Переход к следующему сообщению
stelvic в настоящее время не в онлайне  stelvic
Сообщений: 16
Зарегистрирован: November 2022
Junior Member
Продолжу старую тему https://murcode.ru/forum/2-firebird-interbase/1341280-mon36a ttachments/ чисто ради академического интереса, поскольку практическую часть для себя решил. После той темы обнаружил, что в четверке вопрос решается не только с помощью процедуры с sql security definer, созданной SYSDBA, но и самым прямым способом, запрос:
select * from mon$attachments
выдает все подключения, независимо от того кто его выполняет. А недавно попробовал пятерку и в ней поведение опять такое же как в тройке, т.е.админы видят все подключения, а простые юзеры - только свои.
Эти колебания вышли по недосмотру или по какой-то другой причине? И если недосмотр, то где в четверке или пятерке?

[Обновления: Thu, 12 December 2024 09:33]

Известить модератора

Re: mon$attachments [сообщение #5812 является ответом на сообщение #5811] Thu, 12 December 2024 11:03 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
Не знаю что там за тема, но проблему с мониторингом в FB4 не подтверждаю - не привилегированный юзер видит только свои коннекты.
Где тикет ?
Re: mon$attachments [сообщение #5814 является ответом на сообщение #5812] Thu, 12 December 2024 13:35 Переход к предыдущему сообщениюПереход к следующему сообщению
basid в настоящее время не в онлайне  basid
Сообщений: 166
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
Senior Member
В последнем сообщении "темы": Правда вначале тоже выдал только одну запись с юзером с именем сервака в домене. Но после того как подмапил ему роль rdb$admin уже получил все.
Что, как бы, намекает на природу "бага". В пятёрке, наверное, пользователей с нуля создавали.
Re: mon$attachments [сообщение #5815 является ответом на сообщение #5812] Thu, 12 December 2024 14:13 Переход к предыдущему сообщениюПереход к следующему сообщению
stelvic в настоящее время не в онлайне  stelvic
Сообщений: 16
Зарегистрирован: November 2022
Junior Member
Я воспроизвел таки пример. Сейчас он наверно уже не актуален потому что касается FB4.0.2
Базы перетекли из FB3 через бекап в тройке и рестор в этом самом FB4.0.2
Аутентификация через win_sspi:
create mapping trusted_auth using plugin win_sspi from any user to user;
create mapping usr_adm using plugin win_sspi from group 'имя_группы' to role adm;
еще пара мапов с другими ролями и доменными группами
create mapping rdb_adm using plugin win_sspi from user 'моя доменная учетка' to role rdb$admin;

И вот если к этой отресторенной базе коннектится непривилегированный юзер, то на запрос select * from mon$attachments получает все имееющиеся коннекты.
Что меня смутило, так то что сервер позже я заменил на 4.0.5 (путем замены всех файлов на таковые из архива кроме конфов и security4.fdb) базы при этом не трогал. И такой доступ (полный) ко всем коннектам остался.

Пока пытался воспроизвести пример выяснил, что актуальные FB4 и FB5 после рестора тех же баз ведут себя одинаково, т.е. у непривилегированных юзеров выдают только записи касающиеся их самих.
К тому же тот же FB4.0.2 если базу не ресторить из тройки, а создавать новую, тоже выдает правильный набор коннектов. Правда здесь я не повторял в точности создание все маппингов.
Re: mon$attachments [сообщение #5816 является ответом на сообщение #5815] Thu, 12 December 2024 14:49 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
stelvic
И вот если к этой отресторенной базе коннектится непривилегированный юзер, то на запрос select * from mon$attachments получает все имееющиеся коннекты.
Значит он привилегированный.

Выполни для проверки
SELECT RDB$SYSTEM_PRIVILEGE(MONITOR_ANY_ATTACHMENT) FROM RDB$DATABASE;
Re: mon$attachments [сообщение #5817 является ответом на сообщение #5816] Thu, 12 December 2024 15:05 Переход к предыдущему сообщениюПереход к следующему сообщению
stelvic в настоящее время не в онлайне  stelvic
Сообщений: 16
Зарегистрирован: November 2022
Junior Member
hvlad писал(а) Thu, 12 December 2024 14:49

Значит он привилегированный.

Выполни для проверки
SELECT RDB$SYSTEM_PRIVILEGE(MONITOR_ANY_ATTACHMENT) FROM RDB$DATABASE;
Да. Возвращает:
RDB$SYSTEM_PRIVILEGE
====================
<true>
Но по-идее не должен быть привилегированным.
По крайней мере в базе отресторенной из того же бекапа но пятеркой этот же пользователь с той же ролью возращает false.

[Обновления: Thu, 12 December 2024 15:09]

Известить модератора

Re: mon$attachments [сообщение #5818 является ответом на сообщение #5817] Thu, 12 December 2024 15:26 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
Теперь

SELECT * FROM RDB$ROLES WHERE RDB$ROLE_IN_USE(RDB$ROLE_NAME);
Re: mon$attachments [сообщение #5819 является ответом на сообщение #5818] Thu, 12 December 2024 15:45 Переход к предыдущему сообщениюПереход к следующему сообщению
stelvic в настоящее время не в онлайне  stelvic
Сообщений: 16
Зарегистрирован: November 2022
Junior Member
hvlad писал(а) Thu, 12 December 2024 15:26
Теперь

SELECT * FROM RDB$ROLES WHERE RDB$ROLE_IN_USE(RDB$ROLE_NAME);
fb4.0.2:
RDB$ROLE_NAME     RDB$OWNER_NAME       RDB$DESCRIPTION RDB$SYSTEM_FLAG RDB$SECURITY_CLASS   RDB$SYSTEM_PRIVILEGES
================= ================== ================= =============== ==================== =====================
ADM               SYSDBA                        <null>               0 SQL$1312             FEFFFFFFFFFFFFFF
fb5.0.1:
RDB$ROLE_NAME    RDB$OWNER_NAME        RDB$DESCRIPTION RDB$SYSTEM_FLAG RDB$SECURITY_CLASS   RDB$SYSTEM_PRIVILEGES
================ =================== ================= =============== ==================== =====================
ADM              SYSDBA                         <null>               0 SQL$1444             0000000000000000
Re: mon$attachments [сообщение #5820 является ответом на сообщение #5819] Thu, 12 December 2024 15:54 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
stelvic писал(а) Thu, 12 December 2024 14:45

fb4.0.2:
RDB$ROLE_NAME     RDB$OWNER_NAME       RDB$DESCRIPTION RDB$SYSTEM_FLAG RDB$SECURITY_CLASS   RDB$SYSTEM_PRIVILEGES
================= ================== ================= =============== ==================== =====================
ADM               SYSDBA                        <null>               0 SQL$1312             FEFFFFFFFFFFFFFF
fb5.0.1:
RDB$ROLE_NAME    RDB$OWNER_NAME        RDB$DESCRIPTION RDB$SYSTEM_FLAG RDB$SECURITY_CLASS   RDB$SYSTEM_PRIVILEGES
================ =================== ================= =============== ==================== =====================
ADM              SYSDBA                         <null>               0 SQL$1444             0000000000000000
Ну так что - всё ещё ищем неуловимого Джо ? Или прояснилось ?
Re: mon$attachments [сообщение #5822 является ответом на сообщение #5820] Fri, 13 December 2024 07:44 Переход к предыдущему сообщениюПереход к следующему сообщению
stelvic в настоящее время не в онлайне  stelvic
Сообщений: 16
Зарегистрирован: November 2022
Junior Member
Влад, похоже это ты ищешь неуловимого Джо. Я вижу, что пользователь получился привилегированным, хотя не должен быть таким. Но это уже не актуально для последних версий и FB4 и FB5  В этом посте в конце я написал об этом.
Re: mon$attachments [сообщение #5825 является ответом на сообщение #5822] Fri, 13 December 2024 11:52 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
https://github.com/FirebirdSQL/firebird/issues/7610
Re: mon$attachments [сообщение #5826 является ответом на сообщение #5825] Fri, 13 December 2024 13:24 Переход к предыдущему сообщениюПереход к следующему сообщению
stelvic в настоящее время не в онлайне  stelvic
Сообщений: 16
Зарегистрирован: November 2022
Junior Member
hvlad писал(а) Fri, 13 December 2024 11:52
https://github.com/FirebirdSQL/firebird/issues/7610
Да, это очень похоже. Я правда думал, что это возможно связано с win_ssp, но в том тикете пользователи и роли обычные, так что, похоже, эта проблема была общая.
У меня еще один вопрос, если ты не против.
Пока экспериментировал с mon$attachments создал процедуру:
create or alter procedure ATTACHMENTS
returns (
    MY smallint,
    MON$USER type of SEC$USER_NAME,
    MON$TIMESTAMP type of MON$STATEMENT_TIMER)
sql security definer
as
begin
  for select iif(mon$attachment_id=current_connection,1,0), mon$user,
    mon$timestamp
    from mon$attachments
    where mon$remote_process is not null
    order by mon$timestamp
    into :my, :mon$user, :mon$timestamp
  do suspend;
end
пользователем с ролью rdb$admin, не SYSDBA. Дал права на нее обычным юзерам. Так вот когда селектят из нее, получают только коннекты этого пользователя, создавшего процедуру. Если такую-же процедуру создает SYSDBA, то все ок. Всем видно все коннекты.
Это нормально?
Экспериментировал на сервере Firebird-5.0.1.1469
Правда IBExpert, в котором это проделывал с fbclient.dll 3.0.11.33703

Дополню, что сам пользователь, создавший процедуру, видит все коннекты к базе и с select * from mon$attachments, и с select * from attachments

[Обновления: Fri, 13 December 2024 13:40]

Известить модератора

Re: mon$attachments [сообщение #5828 является ответом на сообщение #5826] Sat, 14 December 2024 14:09 Переход к предыдущему сообщениюПереход к следующему сообщению
hvlad в настоящее время не в онлайне  hvlad
Сообщений: 364
Зарегистрирован: August 2022
Senior Member
stelvic
Пока экспериментировал с mon$attachments создал процедуру:
create or alter procedure ATTACHMENTS
returns (
    MY smallint,
    MON$USER type of SEC$USER_NAME,
    MON$TIMESTAMP type of MON$STATEMENT_TIMER)
sql security definer
as
begin
  for select iif(mon$attachment_id=current_connection,1,0), mon$user,
    mon$timestamp
    from mon$attachments
    where mon$remote_process is not null
    order by mon$timestamp
    into :my, :mon$user, :mon$timestamp
  do suspend;
end
пользователем с ролью rdb$admin, не SYSDBA. Дал права на нее обычным юзерам. Так вот когда селектят из нее, получают только коннекты этого пользователя, создавшего процедуру. Если такую-же процедуру создает SYSDBA, то все ок. Всем видно все коннекты.
Это нормально?
Я не нашёл в стандарте должны ли учитываться роли DEFINER'а при проверке прав.
В коде я вижу использование только имени DEFINER'а, возможно будет учитываться его DEFAULT роль, если она есть.
Не проверял. И я с этим кодо мало знаком.

stelvic
Экспериментировал на сервере Firebird-5.0.1.1469
Правда IBExpert, в котором это проделывал с fbclient.dll 3.0.11.33703
Версия клиента тут не играет никакой роли.

stelvic
Дополню, что сам пользователь, создавший процедуру, видит все коннекты к базе и с select * from mon$attachments, и с select * from attachments
Это в коннекте с явно указанной ролью RDB$AMIN ?
А если роль не указана ?
Re: mon$attachments [сообщение #5829 является ответом на сообщение #5828] Sat, 14 December 2024 16:30 Переход к предыдущему сообщениюПереход к следующему сообщению
stelvic в настоящее время не в онлайне  stelvic
Сообщений: 16
Зарегистрирован: November 2022
Junior Member
hvlad писал(а) Sat, 14 December 2024 14:09
Я не нашёл в стандарте должны ли учитываться роли DEFINER'а при проверке прав.
В коде я вижу использование только имени DEFINER'а, возможно будет учитываться его DEFAULT роль, если она есть.
Не проверял. И я с этим кодо мало знаком.
Ок. Думаю, что большинство людей такое поведение устроит. Меня так точно. Просто нужно помнить о нем.

hvlad писал(а) Sat, 14 December 2024 14:09
stelvic
Дополню, что сам пользователь, создавший процедуру, видит все коннекты к базе и с select * from mon$attachments, и с select * from attachments
Это в коннекте с явно указанной ролью RDB$AMIN ?
А если роль не указана ?
Да в коннекте роль RDB$ADMIN. Это моя админская доменная учетка. А коннект трастед. Когда под ней коннекчусь всегда получаю роль RDB$ADMIN. Ради проверки могу ее убрать. Но это будет только в понедельник, когда на работу приду.
Re: mon$attachments [сообщение #5830 является ответом на сообщение #5829] Mon, 16 December 2024 08:09 Переход к предыдущему сообщению
stelvic в настоящее время не в онлайне  stelvic
Сообщений: 16
Зарегистрирован: November 2022
Junior Member
hvlad писал(а) Sat, 14 December 2024 14:09
stelvic
Дополню, что сам пользователь, создавший процедуру, видит все коннекты к базе и с select * from mon$attachments, и с select * from attachments
Это в коннекте с явно указанной ролью RDB$AMIN ?
А если роль не указана ?
Итак если сначала создать процедуру с sql security definer под юзером с ролью RDB$ADMIN (не SYSDBA), а потом у него эту роль отобрать, то при селекте из нее он видит как и все непривилегированные только свои коннекты. Что логично.
Предыдущая тема: alter table похоже на баг
Следующая тема: Полнотекстовый поиск для Firebird
Переход к форуму:
  


Текущее время: Wed Dec 18 08:47:58 GMT+3 2024

Общее время, затраченное на создание страницы: 0.00951 секунд