Как создать базу данных динамически для 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), производитель ОС и СУБД. А самое главное - прикладной программист, у которого мании преследования и величия одновременно. Потому, что он думает, что его дачный огродик - это полный аналог мирового сельского хозяйства. И при этом даже не знаком с соседом по даче.

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

← →
Danilka (2003-10-08 09:29) [41]

[40] Sergey13 © (08.10.03 09:05)
Добавлю до кучи, на счет угроз, юзер, работающий с базой и имеющий права на изменение данных представляет ничуть не меньше угрозы чем, например, админ.

← →
France (2003-10-08 14:44) [42]

Sergey13 © (08.10.03 09:05) [40]
Danilka © (08.10.03 09:29) [41]

Отвечу сразу на оба момента - если информация является важной и ее изменение несанкционированным образом ведет к: а)сбою в работе системы в целом (вплоть до разрушения БД - т.е. информация после этого будет представлять собой БОЛЬШУЮ кучу мусора); б)невозможности в дальнейшем найти "крайнего" - того, кто сделал каку, - то я предпочитаю, предоставлять доступ к изменению данных только в рамках своего ПО (а значит юзер с кривыми ручками доступ к базе не получит - его получит ПО, которое само создаст базу и само же будет ее вести), а самое главное все остальные угрозы буду решать только в рамках своего ПО (за что могу конечно тоже быть "поглаженным по головке", но это называется ОТВЕТСТВЕННОСТЬЮ). Так что, господа, Ваши аргументы не уместны...

Если б не жадность клиентов, я бы не рыпался в FreeWare БД...

← →
Danilka (2003-10-08 15:40) [43]

[42] France (08.10.03 14:44)
Во-первых - админ это не юзер с кривыми ручками, ему за это деньги платят, за то что у него руки не кривые.
Во-вторых админу абсолютно пофигу содержимое базы.
В третьих, если в базе глюки - то он и есть самый крайний, он и отгребет в случае чего, ибо за это ему деньги платят, как и за то, чтобы всегда бакаб был, а если не будет в нужный момент, то тоже отгребет.
Конечно, если у тебя все так плохо, что пароль sysdba есть у всех юзеров с кривыми ручками, то это уже орг. проблемы, сам виноват. Точно также будешь сам виноват, если всем кому не лень давать доступ к физ.файлам БД.

>Если б не жадность клиентов, я бы не рыпался в FreeWare БД...
А что-бы ты сделал? Расскажи, допустим клиенты купят все, что ты им скажешь, что ты сделаешь?

← →
France (2003-10-08 15:52) [44]

Danilka © (08.10.03 15:40) [43]

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

А если бы клиенты были готовы выкладывать деньги за БД, нашел бы такую в которой администрирование развито на соответствующем уровне (например, Oracle)... Преимущество IB как раз в том, что для его работы, собственно, особого администрирования и не нуно...

← →
Danilka (2003-10-08 16:08) [45]

[44] France (08.10.03 15:52)
В таком случае, скажу тебе по секрету, админ в орокле тоже может посмотреть/изменить любые данные и даже совсем грохнуть базу.
Так что, не будет тебе щастья от оракла. :))

См. вот сюда:
[37] MsGuns © (06.10.03 14:26)
Привел какой-то АДАБАС, который шифрует данные, но я уверен, что даже в нем админ может грохнуть всю базу, несмотря ни на какие шифры.
Значит, никакого выхода нет, гадкий админ все равно может все прибить, о боже, какая низость с его стороны, пора совсем завязывать с программированием.

← →
Danilka (2003-10-08 16:07) [46]

← →
Danilka (2003-10-08 16:19) [47]

А есть вообще СУБД без админа?

← →
France (2003-10-09 14:15) [48]

Danilka © (08.10.03 16:07) [46]

Грохнуть всю базу и изменить данные в текущей базе - немного разные вещи... Правда? С таким успехом любой, кто имеет доступ к фалу БД может грохнуть базу! :) А установить права на файл дистанционно при инсталяции в неизвестной ОС (хорошо, что пока дело ограничевается Windows семейством...) - по моему, это довольно трудно решаемая проблема... :)

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

Еще раз повторю то, что сказал раньше: функция адмитнистратора - спасать в критических ситуациях, когда владелец уже не в состоянии что-либо сделать, а данные представляют ценность... И backup/restore делает уже ДРУГУЮ базу (меняется владелец = тот кто делает эту процедуру)... А мне необходимо и достаточно всего лишь чтобы в МОЕЙ базе никто не мог ничего делать руками - только из UserInterface... :)

← →
Danilka (2003-10-09 14:29) [49]

[48] France (09.10.03 14:15)
>С таким успехом любой, кто имеет доступ к фалу БД может грохнуть базу!
Угу, именно поэтому, должен быть грамотный админ на сервере, недопускающий физ.доступ к файлам БД никому, за исключением СУБД, ну и себя любимого, конечно.

>А установить права на файл дистанционно при инсталяции в неизвестной ОС
А зачем так, дистанционно, в нейзвестной ос, почему напрямую на сервере нельзя?

>А на счет Оракла,
На это тебе уже отвечали:
[26] Sergey13 © (03.10.03 11:01)

>А мне необходимо и достаточно всего лишь чтобы в МОЕЙ базе никто не мог
>ничего делать руками - только из UserInterface...
Думаю, гиблый номер, если только не хранить данные в своем формате. СУБД на то и СУБД, чтобы разруливать любые подключения от любых программ, лишь-бы интерфейс был обоим понятный.
Вобщем, делай как хочешь, устал я, честно говоря, с тобой бодаться.

ps. все-таки, не надо так бояться админов :)

← →
France (2003-10-09 14:40) [50]

Danilka © (09.10.03 14:29) [49]

На КАКОМ сервере??? Ты напсиал программу и отдаешь ее конечному юзеру... Где у него будет сервер, и насколько он опытный в его администрировании??? Именно преимущество IB состоит в том, что такой "сервер" можно практически не администрировать! :) Все что нужно подправляется инсталятором (ну если ставился IB вместе с твоей программой, иначе - оставляй как есть) и работай на здоровье... :)
Блин, я устал объяснять... (то ли лыжи, то ли...)

← →
Danilka (2003-10-09 14:52) [51]

[50] France (09.10.03 14:40)
>На КАКОМ сервере???
На Орокле, например, ты-же его все время нахваливаешь :))

А так, если для одного юзера, то используй наздоровье FB embeded или дятел-персонал. И уж для супер-пупер сикретности, при выходе из программы - что-нибудь правь в файле БД, чтобы никто не мог заломиться обычным серваком. И все дела.

А если многопользовательсякая, то уж, по-любому сервак нужен.

И еще, лидер по продажам подобных систем - 1С, у них все на дбф-ках или МССкуль, что-то они не плачут и даже не беспокоятся, что кто-то может их дбф-ки вручную не из программы править.

Короче, мой диагноз - ищешь себе проблемы там где их нет.

← →
France (2003-10-09 15:01) [52]

Danilka © (09.10.03 14:52) [51]
Интересно, а твой "лидер" занимается в последствии поддержкой своих продуктов и несет за ее работоспособность и достоверность информации ответственность???
Специфика работы, и проблем я не ищу - они есть такие как я описал... Просто другие люди на них плюют или молча решают описанными сепцифическими способами... :/

И не надо меня убеждать в "добропорядочности" и прочих прелестях администратора... Есть конкретная задача и конкретные трудности... Мнение мастеров я выслушал, кое в чем разобрался сходу (мозги значит еще не совсем заржавели), выводы для себя сделал...
Еще раз спасибо всем учавствовавшим... :)

← →
Danilka (2003-10-09 15:32) [53]

[52] France (09.10.03 15:01)
>Интересно, а твой "лидер" занимается в последствии поддержкой своих
>продуктов и несет за ее работоспособность и достоверность информации
>ответственность???
Поддержка это святое, а за работоспособность и достоверность информации порушеные пользователем несет ответственность только сам пользователь. Как я понимаю, ты хочешь взять это на себя. Ну что-же, удачи.

← →
France (2003-10-10 13:53) [54]

Danilka © (09.10.03 15:32) [53]

Да не я хочу, а специфика работы требует! Ну не должен юзер ничего менять, а если изменил, то я об этом (как минимум) должен знать точно, что где и как он наменял и тыкнуть туда его носом... :) Типа, сам полез - сам дурак... Но лучше, если я просто его не пущу что-либо менять... :)

← →
Zacho (2003-10-10 19:03) [55]

> France (10.10.03 13:53) [54]
> Danilka © (09.10.03 15:32) [53]
>
> Да не я хочу, а специфика работы требует! Ну не должен юзер
> ничего менять,

Сделай read-only db.
Уволь всех. Положи диск с базой в Мариинскую впадину :)

← →
France (2003-10-13 10:15) [56]

← →
Sergey13 (2003-10-13 10:55) [57]

2France (13.10.03 10:15) [56]
>А для начала - "застрелись" забыли посоветовать ;)
Это подразумевалось само собой. 8-)

← →
Карелин Артем (2003-10-13 11:01) [58]

France (26.09.03 17:51) [11]
>>Вообщем в итоге всех изысканий: - ограничить SYSDBA нельзя ни как, он имеет доступ ко всему: к системным таблицам базы, к операциям создания, удаления и изменения триггеров и хранимок (в том числе и к пользовательским данным)... Владельца базы смени. И ручками переделай таблицу привелегий (тоже системная). В RDB$roles запиши роль SYSDBA и опять вручную смени OWNER для роли на NULL.
>>- триггер на прямые модификации данных в таблицах (в том числе и системных) в состоянии ограничить SYSDBA, но этот триггер не составляет труда перевести в состояние неактивный, а затем произвести другие операции...

Повесь триггер на изменение системной таблицы с триггерами (RDB$triggers кажись) в котором делай исключительную ситуацию :)) Его только потом нельзя будет поменять...

Кстати при первом входе пользователя в систему обычно добвляются записи в таблицу привелегий. Опять системную.

← →
France (2003-10-27 17:54) [59]

Карелин Артем © (13.10.03 11:01) [58]
Роль я так понял нуно ручками прописать (create role не дает...), а на счет триггера я ужже думал - защитить базу от модификации я могу (понавешивав немерянное количество триггеров на каждую таблицу ;) ), а вот как совсем закрыться... Может Ваш совет будет действенным - попробую! :)

← →
Reindeer Moss Eater (2003-10-27 18:59) [60]

В Марианскую впадину. Мариинская впадина сгорела.

← →
paul_k (2003-10-28 00:43) [61]

мдя.
самый защищенный компь.тер - выключеный.
самый надежный носитель - каменные скрижали (или глинянные таблички - что кому по вкусу) Самое гнусное , что люди со взглядами подобными France попадают работать во всякие "службы внутреннего контроля", "службы информационной безопасности" и начинают мешать жить.
France, если идеш по этому тернистому пути, то сначала подумай а кто у тебя злой, то есть модель нарушителя создай. Потом подумай откуда он придти может. Что порушить и так далее. И придеш к тому, что Aдмину, он же Sa, он же Sysdba и так далее достаточно запретить всего 1 или 2 операции (точнее процедуры), что вполне реально и доступно. А в остальном он "Царь и Бог", но и ответственности на нем намного больше чем на простом усере.

← →
Reindeer Moss Eater (2003-10-28 08:31) [62]

Даже самый надежный носитель не спасет от юзера с достаточными правами (Моисея).

А ответ на заданный вопрос лежит в сфере административных решений, а не программных.

← →
paul_k (2003-10-28 10:05) [63]

← →
France (2003-10-31 13:03) [64]

Карелин Артем © (13.10.03 11:01) [58]

В системную таблицу привилегий при первом входе пользователя записи не добавляются :( Пробывал на firebird... А вот с ролью получилось весьма удачно... Войти от Sysdba теперь нельзя... :)

paul_k © (28.10.03 00:43) [61]

Для особо доходчивых объясняю, специфика ПО требует, чтобы: а) либо велось постоянное протоколирование работы с данными в базе (чтобы потом можно было тыкать в виноватых пальцем); или б) доступ к базе осуществлялся только из ПО (на уровне ПО) - тогда всех неблагонадежных необходимо отсечь (ответственность несет только ПО).... ПО устанавливается у клиентов (а их, ох, как много!), а следовательно изменение каких-либо параметров и настроек на их стороне запрещено... Что посоветуете? Облегчить жизнь клиентам - дать доступ SYSDBA, который (умышленно или нет) войдет мимо ПО и руками решит че нить изменить (а так хотелось посмотреть или подправить самому, так как ПО не дает), а после выставит притензию разработчику (т.е. мне) с требованием компенсации финансовых убытков... И как я должен доказать, чтоо ЭТО НЕ Я в программе своей сделал??? А?

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

Еще раз (в который? "китайский" последний? ;} ) благодарю всех...

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