| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как создать базу данных динамически для Interbase6.0 FireBird1.x? [D6, D7, IB6.x]
France © (2003-09-22 19:14:00)
Требуется динамически создать базу данных FireBird/InterBase6.0.
При этом ограничить к ней доступ всем, кроме одного из пользователей (как добавить пользователя знаю...)
Какие есть мысли? Желательно кодом... :)
France (2003-10-03 10:51:00) [41]
Sergey13 © (03.10.03 10:41) [22]
Естественно я могу защититься программными средствами от всяких SYSDBA... НО хлопотно это все.... В Оракле есть возможность (со слов - не проверял) поставить на процедуру подключения к базе триггер и запретить вход даже System/manager-у...
А под администрированием я имел в виду процесс изменения доступа к данным со стороны других пользователей... :)
Anatoly Podgoretsky (2003-10-03 10:43:00) [42]
France (03.10.03 10:18) [19]
Здраствуй, делаешь смену пароля для SYSDBA следующим образом, закрываешь глаза и набираешь случайные символы.
И не надо административные меры переносить на систему.
sniknik © (03.10.03 10:32) [20]
Включая это SA
Sergey13 (2003-10-03 10:41:00) [43]
2France (03.10.03 10:18) [19]
А че ты так своего дибиэя не любишь? С ним надо дружить. ИМХО, это нормальная политика, когда DBA могет все (или почти все). Во всех БД серьезных вроде так.
>перенесут список пользователей в саму БД и тогда администрировать ее смогут только владельцы
Тут еще вопрос - что ты понимаешь под администрированием.
France (2003-10-03 10:38:00) [44]
Любой юзверь-админ уходя и решив попортить кровушки может сделать каку! Например, поменть пароль тому же root-у... :))))
Суть в следующем, backup можно, restore можно, и база восстановлена... :-) И owner тоже поменялся... И пусть это делает SYSDBA, SA, root... :)
Если подключение идет на уровне программы, то пользователю необязательно знать имя и пароль к базе... :)
sniknik (2003-10-03 10:32:00) [45]
France (03.10.03 10:18) [19]
> Вывод: система безопасности в БД InterBase\FireBird оставляет желать лучшего... :( Один пользователь, имеющий неограниченный досткп ко всему - всегда будет источником потенциальной угрозы для данных! ...
точно!!! и пользователь этот (сисадмин) немало кровушки простым юзверям попортит. только дело в том что ни одна система без такого пользователя не обходится, в виндах это Администратор в Linux это root в MSSQL это SA в .... это ....
(а если и есть такая система, то это еще хуже, подержке и администрированию она не будет поддаватся в принципе из принципа ;о)), ну к примеру увольняется обиженный юзер откудато взял да и пеменял свой пароль на свою базу ... и(?) что делать? данные то им набитые на рабочем месте ему не принадлежат. ну и т.д. и т.п.)
кстати в MSSQL строго рекомендуется сисадмину на SA ставить пароль и никому его не давать...
France (2003-10-03 10:18:00) [46]
Вообщем в итоге всех изысканий:
- ограничить SYSDBA нельзя ни как, он имеет доступ ко всему: к системным таблицам базы, к операциям создания, удаления и изменения триггеров и хранимок (в том числе и к пользовательским данным)...
- триггер на прямые модификации данных в таблицах (в том числе и системных) в состоянии ограничить SYSDBA, но этот триггер не составляет труда перевести в состояние неактивный, а затем произвести другие операции...
Вывод: система безопасности в БД InterBase\FireBird оставляет желать лучшего... :( Один пользователь, имеющий неограниченный досткп ко всему - всегда будет источником потенциальной угрозы для данных! :( Надеюсь в FireBird 2.0 наконец-то перенесут список пользователей в саму БД и тогда администрировать ее смогут только владельцы (owners)...
France (2003-09-29 12:07:00) [47]
Проверь, на всяк случай...
В FireBird 1.0.3 - не могу никак... :(
Единственный выход - ограничить SysDba триггерами (как не печально)...
Zacho (2003-09-26 19:07:00) [48]
> France (26.09.03 18:26) [15]
В IB 6.x (насколько помню) - могу.
France (2003-09-26 18:42:00) [49]
И почему сразу не перенести security на базу?!!! Кто создал ее, тот и администрит... А то ограничвай теперь SYSDBA с его магическим волшебным именем... :(
France (2003-09-26 18:26:00) [50]
Обижаешь.... Роль SYSDBA ты создать не можешь.... :( Попробуй, прежде чем писать!
Zacho (2003-09-26 18:16:00) [51]
Ты точно создал роль SYSDBA ? Именно CREATE ROLE SYSDBA ?
France (2003-09-26 18:06:00) [52]
Пробывал - если не указать при подключении эту самую роль (а кто ж ее будет указывать в isql???), то SYSDBA на нее просто наплевать... :(
Zacho (2003-09-26 18:04:00) [53]
Создай роль с именем SYSDBA и посмотри, что после этого произойдет при подключении SYSDBA
France (2003-09-26 17:51:00) [54]
Уважаемые мастера! Взываю к вашей компетентности..... И так, из выше перечисленного ничего толкового нет... :(
Проблема остается такая же - существует некая база, необходимо при ее динамическом создании на стороне клиента, создать соответствующего пользователя (подключившись как SYSDBA), создать базу (динамически или положить созданную) и ограничить при этом права хотя бы на модификацию данных (а желательно полностью) других пользователей!!!
Пользователи хранятся в системной базе данных сервера, при этом SYSDBA обладает правами root-а (может все)... Ограничить его мне удалось только выставив триггер на таблицу, в которой он пытался произвести изменения... (правда для всех возможных изменений, триггеров должно быть три!) Никакие системные таблицы при подключении пользователя к базе не обновляются (а следовательно выставить на них триггер нет возможности)... Роли SYSDBA игнорирует (если их не указывать), а удаление прав PUBLIC из системной таблицы БД эффекта никакого не дает (для SYSDBA)...
Как вариант решения - выставить триггеры на ВСЕ таблицы (по три на каждую...). Может знает кто-нибудь более изящное решение???
France (2003-09-25 12:46:00) [55]
Так все таки, какие есть еще решения для запрета доступа к базе со стороны других пользователей? С триггерами еще не смотрел...
Zacho (2003-09-23 19:04:00) [56]
> Карелин Артем © (23.09.03 09:48) [6]
> Сделай роль sysdba для запрета логина админа, разберись
> с поведением системных таблиц при логинах к базе -> на какую-то
> из таблиц можно повесить триггер, который фактически станет
> триггером на вход в систему.
А можно подробнее на счет триггера ? Сколько не пробовал, не разу не замечал изменения каких-либо системных таблиц при логинеюзера. Или я просто не туда смотрел ? Правда, интересно.
France (2003-09-23 16:25:00) [57]
[4] SYSDBA нужно как раз оставить в первозданном виде (а что если у клиента уже стоит Ib6 и он поменял ему SYSDBA пароль?), а вот ограничить его права на доступ к базе мне и надо... М вообще никого туда не пускать кроме моего пользователя-администратора... :)
[6] мне подходит больше всего... :)
kaif (2003-09-23 12:41:00) [58]
Для начала пароль SYSDBA измени с masterkey на тот, который только один чувак будет знать. Однако если этот чувак имеет доступ на запись к файлу isc4.gdb (база паролей в IB6.0), то, заменив этот файл на свой аналог (с помощью "Проводника" Windows), он затем получит доступ к базе. Так что системный администратор Windows в принципе всегда может получить доступ к базе, если он сечет в IB.
Карелин Артем (2003-09-23 09:48:00) [59]
Сделай роль sysdba для запрета логина админа, разберись с поведением системных таблиц при логинах к базе -> на какую-то из таблиц можно повесить триггер, который фактически станет триггером на вход в систему. Если в этом триггере генерить исключительную ситуацию, пользователь обломится на входе. Не работает на входе владельца базы.
Делал сравнительно давно, точного названия таблицы не помню. А еще для этого нужно убирать права для PUBLIC из таблицы с правами юзеров.
Armaniak (2003-09-23 09:21:00) [60]
Если я правильно понял после создания требуется чтобы только один мог работать с этой базой, так почему не может подходить предыдущий ответ с изменением пароля на всю базу если она динамически изменяется, то просто определяешь со своим паролем её создание и делай с ней что хочешь, как админ.
| |
Страницы: 