Как создать базу данных динамически для Interbase6.0 FireBird1.x?

← →
France (2003-09-22 19:14) [0]

Требуется динамически создать базу данных FireBird/InterBase6.0.
При этом ограничить к ней доступ всем, кроме одного из пользователей (как добавить пользователя знаю...)
Какие есть мысли? Желательно кодом... :)

← →
jack128 (2003-09-22 19:39) [1]

TIBDatabase.CreateDatabase + F1

← →
France (2003-09-23 08:32) [2]

А чтобы пользователь (только один) имел доступ к ней? Например, я не хочу чтобы, кто-то войдя как SYSDBA выполнял какие-либо запросы в том же isql...

← →
Armaniak (2003-09-23 08:54) [3]

А на что такая инструкция при создании базы
CREATE {DATABASE | SCHEMA} ’ filespec’
[USER ’ username’ [PASSWORD ’ password’]]...

← →
Deniz (2003-09-23 09:14) [4]

Пользователи хранятся в другом файле, и SYSDBA имеет все права на все создаваемые БД на этом сервере. Так что ограничить можно только других пользователей, но не SYSDBA

← →
Armaniak (2003-09-23 09:21) [5]

Если я правильно понял после создания требуется чтобы только один мог работать с этой базой, так почему не может подходить предыдущий ответ с изменением пароля на всю базу если она динамически изменяется, то просто определяешь со своим паролем её создание и делай с ней что хочешь, как админ.

← →
Карелин Артем (2003-09-23 09:48) [6]

Сделай роль sysdba для запрета логина админа, разберись с поведением системных таблиц при логинах к базе -> на какую-то из таблиц можно повесить триггер, который фактически станет триггером на вход в систему. Если в этом триггере генерить исключительную ситуацию, пользователь обломится на входе. Не работает на входе владельца базы.
Делал сравнительно давно, точного названия таблицы не помню. А еще для этого нужно убирать права для PUBLIC из таблицы с правами юзеров.

← →
kaif (2003-09-23 12:41) [7]

Для начала пароль SYSDBA измени с masterkey на тот, который только один чувак будет знать. Однако если этот чувак имеет доступ на запись к файлу isc4.gdb (база паролей в IB6.0), то, заменив этот файл на свой аналог (с помощью "Проводника" Windows), он затем получит доступ к базе. Так что системный администратор Windows в принципе всегда может получить доступ к базе, если он сечет в IB.

← →
France (2003-09-23 16:25) [8]

[4] SYSDBA нужно как раз оставить в первозданном виде (а что если у клиента уже стоит Ib6 и он поменял ему SYSDBA пароль?), а вот ограничить его права на доступ к базе мне и надо... М вообще никого туда не пускать кроме моего пользователя-администратора... :)
[6] мне подходит больше всего... :)

← →
Zacho (2003-09-23 19:04) [9]

> Карелин Артем © (23.09.03 09:48) [6]
> Сделай роль sysdba для запрета логина админа, разберись
> с поведением системных таблиц при логинах к базе -> на какую-то
> из таблиц можно повесить триггер, который фактически станет
> триггером на вход в систему.

А можно подробнее на счет триггера ? Сколько не пробовал, не разу не замечал изменения каких-либо системных таблиц при логине юзера. Или я просто не туда смотрел ? Правда, интересно.

← →
France (2003-09-25 12:46) [10]

Так все таки, какие есть еще решения для запрета доступа к базе со стороны других пользователей? С триггерами еще не смотрел...

← →
France (2003-09-26 17:51) [11]

Уважаемые мастера! Взываю к вашей компетентности..... И так, из выше перечисленного ничего толкового нет... :(

Проблема остается такая же - существует некая база, необходимо при ее динамическом создании на стороне клиента, создать соответствующего пользователя (подключившись как SYSDBA), создать базу (динамически или положить созданную) и ограничить при этом права хотя бы на модификацию данных (а желательно полностью) других пользователей!!!

Пользователи хранятся в системной базе данных сервера, при этом SYSDBA обладает правами root-а (может все)... Ограничить его мне удалось только выставив триггер на таблицу, в которой он пытался произвести изменения... (правда для всех возможных изменений, триггеров должно быть три!) Никакие системные таблицы при подключении пользователя к базе не обновляются (а следовательно выставить на них триггер нет возможности)... Роли SYSDBA игнорирует (если их не указывать), а удаление прав PUBLIC из системной таблицы БД эффекта никакого не дает (для SYSDBA)...

Как вариант решения - выставить триггеры на ВСЕ таблицы (по три на каждую...). Может знает кто-нибудь более изящное решение???

← →
Zacho (2003-09-26 18:04) [12]

Создай роль с именем SYSDBA и посмотри, что после этого произойдет при подключении SYSDBA

← →
France (2003-09-26 18:06) [13]

Пробывал - если не указать при подключении эту самую роль (а кто ж ее будет указывать в isql???), то SYSDBA на нее просто наплевать... :(

← →
Zacho (2003-09-26 18:16) [14]

Ты точно создал роль SYSDBA ? Именно CREATE ROLE SYSDBA ?

← →
France (2003-09-26 18:26) [15]

Обижаешь.... Роль SYSDBA ты создать не можешь.... :( Попробуй, прежде чем писать!

← →
France (2003-09-26 18:42) [16]

И почему сразу не перенести security на базу?!!! Кто создал ее, тот и администрит... А то ограничвай теперь SYSDBA с его магическим волшебным именем... :(

← →
Zacho (2003-09-26 19:07) [17]

> France (26.09.03 18:26) [15]

В IB 6.x (насколько помню) - могу.

← →
France (2003-09-29 12:07) [18]

Проверь, на всяк случай...
В FireBird 1.0.3 - не могу никак... :(
Единственный выход - ограничить SysDba триггерами (как не печально)...

← →
France (2003-10-03 10:18) [19]

Вообщем в итоге всех изысканий:
- ограничить SYSDBA нельзя ни как, он имеет доступ ко всему: к системным таблицам базы, к операциям создания, удаления и изменения триггеров и хранимок (в том числе и к пользовательским данным)...
- триггер на прямые модификации данных в таблицах (в том числе и системных) в состоянии ограничить SYSDBA, но этот триггер не составляет труда перевести в состояние неактивный, а затем произвести другие операции...

Вывод: система безопасности в БД InterBase\FireBird оставляет желать лучшего... :( Один пользователь, имеющий неограниченный досткп ко всему - всегда будет источником потенциальной угрозы для данных! :( Надеюсь в FireBird 2.0 наконец-то перенесут список пользователей в саму БД и тогда администрировать ее смогут только владельцы (owners)...

← →
sniknik (2003-10-03 10:32) [20]

France (03.10.03 10:18) [19]
> Вывод: система безопасности в БД InterBase\FireBird оставляет желать лучшего... :( Один пользователь, имеющий неограниченный досткп ко всему - всегда будет источником потенциальной угрозы для данных! ...
точно!!! и пользователь этот (сисадмин) немало кровушки простым юзверям попортит. только дело в том что ни одна система без такого пользователя не обходится, в виндах это Администратор в Linux это root в MSSQL это SA в .... это ....
(а если и есть такая система, то это еще хуже, подержке и администрированию она не будет поддаватся в принципе из принципа ;о)), ну к примеру увольняется обиженный юзер откудато взял да и пеменял свой пароль на свою базу ... и(?) что делать? данные то им набитые на рабочем месте ему не принадлежат. ну и т.д. и т.п.)
кстати в MSSQL строго рекомендуется сисадмину на SA ставить пароль и никому его не давать...

← →
France (2003-10-03 10:38) [21]

Любой юзверь-админ уходя и решив попортить кровушки может сделать каку! Например, поменть пароль тому же root-у... :))))
Суть в следующем, backup можно, restore можно, и база восстановлена... :-) И owner тоже поменялся... И пусть это делает SYSDBA, SA, root... :)
Если подключение идет на уровне программы, то пользователю необязательно знать имя и пароль к базе... :)

← →
Sergey13 (2003-10-03 10:41) [22]

2France (03.10.03 10:18) [19]
А че ты так своего дибиэя не любишь? С ним надо дружить. ИМХО, это нормальная политика, когда DBA могет все (или почти все). Во всех БД серьезных вроде так.

>перенесут список пользователей в саму БД и тогда администрировать ее смогут только владельцы
Тут еще вопрос - что ты понимаешь под администрированием.

← →
Anatoly Podgoretsky (2003-10-03 10:43) [23]

France (03.10.03 10:18) [19]
Здраствуй, делаешь смену пароля для SYSDBA следующим образом, закрываешь глаза и набираешь случайные символы.
И не надо административные меры переносить на систему.

sniknik © (03.10.03 10:32) [20]
Включая это SA

← →
France (2003-10-03 10:51) [24]

Sergey13 © (03.10.03 10:41) [22]

Естественно я могу защититься программными средствами от всяких SYSDBA... НО хлопотно это все.... В Оракле есть возможность (со слов - не проверял) поставить на процедуру подключения к базе триггер и запретить вход даже System/manager-у...

А под администрированием я имел в виду процесс изменения доступа к данным со стороны других пользователей... :)

← →
France (2003-10-03 10:54) [25]

Anatoly Podgoretsky © (03.10.03 10:43) [23]

Делать смену пароля SYSDBA я не могу, тем более не глядя...! Как я могу гарантировать, что этот пользователь (root) не используется в других программах? Моя прога значит станет, пароль сменит, а остальным - застрелится??? :)

← →
Sergey13 (2003-10-03 11:01) [26]

2France (03.10.03 10:51) [24]
>В Оракле есть возможность (со слов - не проверял) поставить на процедуру подключения к базе триггер и запретить вход даже System/manager-у...
Ты наверное недослушал те слова. Тригер поставить можно, но при входе sys-ом сервак пилюет на эти тригеры.

>А под администрированием я имел в виду процесс изменения доступа к данным со стороны других пользователей... :)
Это очень маленькая часть работы DBA. Да и вообще не его это работа, а именно владельца схемы (в терминологии Оракла). Тем паче что ДБА и не может этого.

← →
France (2003-10-03 11:12) [27]

Sergey13 © (03.10.03 11:01) [26]

Как раз слова я дослушал... Просто этого наверное не проверял и тот человек, кто мне данную информацию дал...
Я все равно склоняюсь к тому мнению, что создавая "Бога" в рамках БД, велик шанс нарваться на то, что кто-то возьмет функции "творца" в свои руки и похацкает все и вся... Процесс реализации возможностей суперпользователя должен быть достаточно сложным и трудоемким процессом, чтобы использовать эти возможности в крайних случаях.... Это к слову...

А для ДБА нет ничего не возможного, в этом (увы) убедился сам... И делает он это все с легкостью из обыкновенного isql... Хочешь - попробуй.... У меня на firebird 1.0.3 sysdba имеет полную вседозволенность... :)

← →
Sergey13 (2003-10-03 11:26) [28]

2France (03.10.03 11:12) [27]
>велик шанс нарваться на то, что кто-то возьмет функции "творца" в свои руки и похацкает все и вся...
Вообще то этот "Бог" и призван с этим бороться. Более того он именно за это и отвечает. И именно от него требуют, что бы крутилось все с минимальными простоями, или вообще без них. Ты вспомни поговорку "у семи нянек дитя без глазу". Это как раз тот случай.

← →
mOOx_ (2003-10-03 11:39) [29]

France, хр парить! РУТ он на то и РУТ, чтоб все и везде. И нефиг тут притензии предъявлять к тем принципам, которые начали вырабатывались еще задолго до того, как ты на свет появился. Если так сделано, значит по другому никак. Без человеческого фактора эта схема не работоспособна. Смени пароль дба и все тут. Запиши его на бумажку, прочитай 3 раза и сожги ее.
ЗЫ: Надеюсь, матом меня никто не кроет :)

← →
France (2003-10-03 15:37) [30]

Sergey13 © (03.10.03 11:26) [28]
mOOx_ © (03.10.03 11:39) [29]

Матами обкладывать в школе так и не научили, хотя физкультуру любил... :)
НО вот принципы поколебать могу.... Да, рут всемогущий, но от этого и все траблы - как сохранить конфиденциальность информации? Поменять пароль руту нельзя (!!!), не хочу и не буду... Хранить инфу зашифрованную - велика радость... Конечно, может это издержки OpenSource? :) Нафиг им конфиденциальность... Куда-нить, лишь бы не в текстовые файлы! :)
Че-то я разгарячился.... Это то, что касается принципов... Рут в системе отличается от рута для БД в моем представлении... Для БД рут должен выполнять функции реаниматора (ну когда уже совсем плохо).

← →
mOOx_ (2003-10-04 12:07) [31]

А если ты руту все обрежешь? Как он будет реанимировать, меня итересует? Я так понял, что инфа НУ ОЧЕНЬ ВАЖНА. Значит шифруй (сам и предложил :) ). По поводу "...рут всемогущий, но от этого и все траблы ...": а ты заранее прикинь, сколько будет траблов, если ты рута из рута в банального юзера запишешь! РАзработчики, значит, делают все, чтоб рута не урезали в правах, а ты хочешь разработчиков обмануть. Проще, наверное, вынь98 поламать :). Вообщем, шифруй в таком случае. Хотя бы какой-нибуть банальной логикой. Хотяб напрямую будет не понятно. Можно еще таблицам названия дать типа "123456" или "йцукен" или "qwerty". И пусть гадские хацкеры головы ломают: что там у тебя храниться. Прогу компильни и удали исходники, чтоб уж алгоритм шифрования не выведали и т.д. и т.п.

Удачи :)

← →
France (2003-10-06 13:33) [32]

mOOx_ © (04.10.03 12:07) [31]
>А если ты руту все обрежешь? Как он будет реанимировать, меня >итересует?
А так же как и в данном случае... Backup|Restore - никто не отменял... :) Кроме того процесс реанимации всегда можно сделать изящным.... :) Реанимация со стороны рута - это крайняя мера, остальное дело owner-a... Да и потом, никто не собирается отбирать права у рута, суть такова, что на базе созданной не им, он всего лишь наблюдатель да, в крайнем случае, тот самый главный дохтор... :)

А с шифрованием - это можно и сколько угодно... :) Насколько это будет удобно? А если я хочу предоставить доступ "только чтение" в последстивии для какого-нить юзера и скажу "по-секрету" это пользователям в программе...?

← →
MsGuns (2003-10-06 13:54) [33]

Может, стоит поинтересоваться, как этот вопрос (конфеденциальность) решается, к примеру, в Novell - фирме, много собак съевшей именно в подобных вопросах. Там тоже есть Supervisor со своим пассвордом, но есть еще и группы и юзера, которые имеют свои права, но ТОЛЬКО В ПРЕДЕЛАХ СВОИХ КАТАЛОГОВ.
Принцип такой - сисадмин (supervisor) могет убить любого юзера или даже группу, но НЕ МОЖЕТ ПРОЧИТАТЬ СОДЕРЖИМОЕ ИХ КАТАЛОГОВ. (А вот удалить может !).
А вот в БД почему-то прнят другой стандарт.

← →
France (2003-10-06 13:59) [34]

MsGuns © (06.10.03 13:54) [33]

Вот это-то мне и не понятно... :) Зачем делать БОГА, чтобы потом ждать от него сюрпризов... Я в любую базу в IB зайду как SYSDBA и наваяю по образу и подобию своему... Честно говоря я расчитывал на более содержательную политику безопасности... Обманулся...

← →
Danilka (2003-10-06 14:14) [35]

[34] France (06.10.03 13:59)
В любую - не зайдешь, если не будешь знать пароля sysdba и не будешь иметь физический доступ к БД.

Приведи, плиз, пример какой-нибудь СУБД, в которой было-бы по другому, пусть хотя-бы и самой-пресамой дорогой? :))

>Зачем делать БОГА, чтобы потом ждать от него сюрпризов...
Делать бога, чтобы он отгреб, если вдруг в базе будут какие-то сюрпризы, или утечка информации. Повторяю, в любой БД обстоит дело так. Обратись в открытым письмом к разработчикам Орокла, МС-СКЛ-а, ИБ, ФиреБирда и проч., пусть устранят, лично для тебя, эту проблемку.

← →
France (2003-10-06 14:25) [36]

Danilka © (06.10.03 14:14) [35]

Устранить "проблемку" и сами могем... :) На это и учились... а сорсники FireBird для этого я уже выкачал... Вопрос весь заключается: а) в концепции БД, которую я считаю немного странноватой (как минимум) и говорить, что так делают все, здесь не уместно... б) в конфиденциальности - это можно решить разными путями (раз не позаботились разработчики БД) в) в том, какой из вариантов пункта (б) выбрать, дабы уменьшить трудозатраты и при этом не ухудшить функциональных возможностей продукта... :)

Спасибо всем, кто откликнулся и давал советы...
Думаю, что тема себя уже исчерпала в рамках данного форума... :)
Удачи...

← →
MsGuns (2003-10-06 14:26) [37]

>Danilka © (06.10.03 14:14) [35]
>Приведи, плиз, пример какой-нибудь СУБД, в которой было-бы по другому, пусть хотя-бы и самой-пресамой дорогой? :))

ADABAS. Насколько помню, там был владелец шифра (или что-то в этом духе). Причем буквально на каждую таблу и даже домен.

← →
Danilka (2003-10-06 14:40) [38]

[37] MsGuns © (06.10.03 14:26)
Интересный подход. А как быть с индексами, они тоже шифруются? Боюсь, что все это может быть в ущерб скорости.

Все-таки я считаю что это экзотика. Для СуперМегаСикретных данных, просмотр которых нельзя доверить админу, даже под страхом кастрации, можно предусмотреть шифрование на клиенте, и в базу ложить уже в зашифрованом виде.

← →
France (2003-10-07 17:31) [39]

Danilka © (06.10.03 14:40) [38]

> Для СуперМегаСикретных данных, просмотр которых нельзя доверить админу, даже под страхом кастрации,
А как быть с ИЗМЕНЕНИЕМ данных???
Пусть смотрит - это уж вопрос такой.... Но вносить изменения - извольте... Именно об этом и идет речь!
>можно предусмотреть шифрование на клиенте, и в базу ложить уже в >зашифрованом виде.
Можно, но суть проблемы не меняется - админ является угрозой (потенциальной) для данных хранящихся в базе...

← →
Sergey13 (2003-10-08 09:05) [40]

Может и не стоило поднимать ветку, но стерпеть не мог... 8-(

2France (07.10.03 17:31) [39]
>админ является угрозой (потенциальной) для данных хранящихся в базе...

Угрозой является еще Чубайс (он всегда виноват, потому что рыжий 8-), вырубающий электричество, производители компонентов компьютера (всех, особенно HDD), производитель ОС и СУБД. А самое главное - прикладной программист, у которого мании преследования и величия одновременно. Потому, что он думает, что его дачный огродик - это полный аналог мирового сельского хозяйства. И при этом даже не знаком с соседом по даче.

ЗЫ: Ветку ИМХО в "потрепаться".

Как создать базу данных динамически для Interbase6.0 FireBird1.x? Найти похожие ветки