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

← →
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]

Zacho © (10.10.03 19:03) [55]
А для начала - "застрелись" забыли посоветовать ;)

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

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

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 не дает...), а на счет триггера я ужже думал - защитить базу от модификации я могу (понавешивав немерянное количество триггеров на каждую таблицу ;) ), а вот как совсем закрыться... Может Ваш совет будет действенным - попробую! :)

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

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

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

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

← →
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? Найти похожие ветки