| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / 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-31 13:03:00) [1]
Карелин Артем © (13.10.03 11:01) [58]
В системную таблицу привилегий при первом входе пользователя записи не добавляются :( Пробывал на firebird... А вот с ролью получилось весьма удачно... Войти от Sysdba теперь нельзя... :)
paul_k © (28.10.03 00:43) [61]
Для особо доходчивых объясняю, специфика ПО требует, чтобы: а) либо велось постоянное протоколирование работы с данными в базе (чтобы потом можно было тыкать в виноватых пальцем); или б) доступ к базе осуществлялся только из ПО (на уровне ПО) - тогда всех неблагонадежных необходимо отсечь (ответственность несет только ПО).... ПО устанавливается у клиентов (а их, ох, как много!), а следовательно изменение каких-либо параметров и настроек на их стороне запрещено... Что посоветуете? Облегчить жизнь клиентам - дать доступ SYSDBA, который (умышленно или нет) войдет мимо ПО и руками решит че нить изменить (а так хотелось посмотреть или подправить самому, так как ПО не дает), а после выставит притензию разработчику (т.е. мне) с требованием компенсации финансовых убытков... И как я должен доказать, чтоо ЭТО НЕ Я в программе своей сделал??? А?
Умников хватает, но "облегчать жизнь" таким "умникам" я не собираюсь...
От модификации данных я защитится смогу, хотелось еще бы и от просмотра... Но это уже не так (жизненно) важно... :)
Еще раз (в который? "китайский" последний? ;} ) благодарю всех...
paul_k (2003-10-28 10:05:00) [2]
Reindeer Moss Eater © (28.10.03 08:31) [62]
Полностью согласен
Reindeer Moss Eater (2003-10-28 08:31:00) [3]
Даже самый надежный носитель не спасет от юзера с достаточными правами (Моисея).
А ответ на заданный вопрос лежит в сфере административных решений, а не программных.
paul_k (2003-10-28 00:43:00) [4]
мдя.
самый защищенный компь.тер - выключеный.
самый надежный носитель - каменные скрижали (или глинянные таблички - что кому по вкусу) Самое гнусное , что люди со взглядами подобными France попадают работать во всякие "службы внутреннего контроля", "службы информационной безопасности" и начинают мешать жить.
France, если идеш по этому тернистому пути, то сначала подумай а кто у тебя злой, то есть модель нарушителя создай. Потом подумай откуда он придти может. Что порушить и так далее. И придеш к тому, что Aдмину, он же Sa, он же Sysdba и так далее достаточно запретить всего 1 или 2 операции (точнее процедуры), что вполне реально и доступно. А в остальном он "Царь и Бог", но и ответственности на нем намного больше чем на простом усере.
Reindeer Moss Eater (2003-10-27 18:59:00) [5]
В Марианскую впадину. Мариинская впадина сгорела.
France (2003-10-27 17:54:00) [6]
Карелин Артем © (13.10.03 11:01) [58]
Роль я так понял нуно ручками прописать (create role не дает...), а на счет триггера я ужже думал - защитить базу от модификации я могу (понавешивав немерянное количество триггеров на каждую таблицу ;) ), а вот как совсем закрыться... Может Ваш совет будет действенным - попробую! :)
Карелин Артем (2003-10-13 11:01:00) [7]
France (26.09.03 17:51) [11]
>>Вообщем в итоге всех изысканий:Владельца базы смени. И ручками переделай таблицу привелегий (тоже системная). В RDB$roles запиши роль SYSDBA и опять вручную смени OWNER для роли на NULL.
- ограничить SYSDBA нельзя ни как, он имеет доступ ко всему: к системным таблицам базы, к операциям создания, удаления и изменения триггеров и хранимок (в том числе и к пользовательским данным)...
>>- триггер на прямые модификации данных в таблицах (в том числе и системных) в состоянии ограничить SYSDBA, но этот триггер не составляет труда перевести в состояние неактивный, а затем произвести другие операции...
Повесь триггер на изменение системной таблицы с триггерами (RDB$triggers кажись) в котором делай исключительную ситуацию :)) Его только потом нельзя будет поменять...
Кстати при первом входе пользователя в систему обычно добвляются записи в таблицу привелегий. Опять системную.
Sergey13 (2003-10-13 10:55:00) [8]
2France (13.10.03 10:15) [56]
>А для начала - "застрелись" забыли посоветовать ;)
Это подразумевалось само собой. 8-)
France (2003-10-13 10:15:00) [9]
Zacho © (10.10.03 19:03) [55]
А для начала - "застрелись" забыли посоветовать ;)
Zacho (2003-10-10 19:03:00) [10]
> France (10.10.03 13:53) [54]
> Danilka © (09.10.03 15:32) [53]
>
> Да не я хочу, а специфика работы требует! Ну не должен юзер
> ничего менять,
Сделай read-only db.
Уволь всех. Положи диск с базой в Мариинскую впадину :)
France (2003-10-10 13:53:00) [11]
Danilka © (09.10.03 15:32) [53]
Да не я хочу, а специфика работы требует! Ну не должен юзер ничего менять, а если изменил, то я об этом (как минимум) должен знать точно, что где и как он наменял и тыкнуть туда его носом... :) Типа, сам полез - сам дурак... Но лучше, если я просто его не пущу что-либо менять... :)
Danilka (2003-10-09 15:32:00) [12]
[52] France (09.10.03 15:01)
>Интересно, а твой "лидер" занимается в последствии поддержкой своих
>продуктов и несет за ее работоспособность и достоверность информации
>ответственность???
Поддержка это святое, а за работоспособность и достоверность информации порушеные пользователем несет ответственность только сам пользователь. Как я понимаю, ты хочешь взять это на себя. Ну что-же, удачи.
France (2003-10-09 15:01:00) [13]
Danilka © (09.10.03 14:52) [51]
Интересно, а твой "лидер" занимается в последствии поддержкой своих продуктов и несет за ее работоспособность и достоверность информации ответственность???
Специфика работы, и проблем я не ищу - они есть такие как я описал... Просто другие люди на них плюют или молча решают описанными сепцифическими способами... :/
И не надо меня убеждать в "добропорядочности" и прочих прелестях администратора... Есть конкретная задача и конкретные трудности... Мнение мастеров я выслушал, кое в чем разобрался сходу (мозги значит еще не совсем заржавели), выводы для себя сделал...
Еще раз спасибо всем учавствовавшим... :)
Danilka (2003-10-09 14:52:00) [14]
[50] France (09.10.03 14:40)
>На КАКОМ сервере???
На Орокле, например, ты-же его все время нахваливаешь :))
А так, если для одного юзера, то используй наздоровье FB embeded или дятел-персонал. И уж для супер-пупер сикретности, при выходе из программы - что-нибудь правь в файле БД, чтобы никто не мог заломиться обычным серваком. И все дела.
А если многопользовательсякая, то уж, по-любому сервак нужен.
И еще, лидер по продажам подобных систем - 1С, у них все на дбф-ках или МССкуль, что-то они не плачут и даже не беспокоятся, что кто-то может их дбф-ки вручную не из программы править.
Короче, мой диагноз - ищешь себе проблемы там где их нет.
France (2003-10-09 14:40:00) [15]
Danilka © (09.10.03 14:29) [49]
На КАКОМ сервере??? Ты напсиал программу и отдаешь ее конечному юзеру... Где у него будет сервер, и насколько он опытный в его администрировании??? Именно преимущество IB состоит в том, что такой "сервер" можно практически не администрировать! :) Все что нужно подправляется инсталятором (ну если ставился IB вместе с твоей программой, иначе - оставляй как есть) и работай на здоровье... :)
Блин, я устал объяснять... (то ли лыжи, то ли...)
Danilka (2003-10-09 14:29:00) [16]
[48] France (09.10.03 14:15)
>С таким успехом любой, кто имеет доступ к фалу БД может грохнуть базу!
Угу, именно поэтому, должен быть грамотный админ на сервере, недопускающий физ.доступ к файлам БД никому, за исключением СУБД, ну и себя любимого, конечно.
>А установить права на файл дистанционно при инсталяции в неизвестной ОС
А зачем так, дистанционно, в нейзвестной ос, почему напрямую на сервере нельзя?
>А на счет Оракла,
На это тебе уже отвечали:
[26] Sergey13 © (03.10.03 11:01)
>А мне необходимо и достаточно всего лишь чтобы в МОЕЙ базе никто не мог
>ничего делать руками - только из UserInterface...
Думаю, гиблый номер, если только не хранить данные в своем формате. СУБД на то и СУБД, чтобы разруливать любые подключения от любых программ, лишь-бы интерфейс был обоим понятный.
Вобщем, делай как хочешь, устал я, честно говоря, с тобой бодаться.
ps. все-таки, не надо так бояться админов :)
France (2003-10-09 14:15:00) [17]
Danilka © (08.10.03 16:07) [46]
Грохнуть всю базу и изменить данные в текущей базе - немного разные вещи... Правда? С таким успехом любой, кто имеет доступ к фалу БД может грохнуть базу! :) А установить права на файл дистанционно при инсталяции в неизвестной ОС (хорошо, что пока дело ограничевается Windows семейством...) - по моему, это довольно трудно решаемая проблема... :)
А на счет Оракла, то по непроверенным данным (со слов одного из наших разработчиков оракловых), там вроде есть возможность установления триггера на подключение к базе, а следовательно и ограничения доступа к ней...
Еще раз повторю то, что сказал раньше: функция адмитнистратора - спасать в критических ситуациях, когда владелец уже не в состоянии что-либо сделать, а данные представляют ценность... И backup/restore делает уже ДРУГУЮ базу (меняется владелец = тот кто делает эту процедуру)... А мне необходимо и достаточно всего лишь чтобы в МОЕЙ базе никто не мог ничего делать руками - только из UserInterface... :)
Danilka (2003-10-08 16:19:00) [18]
А есть вообще СУБД без админа?
Danilka (2003-10-08 16:08:00) [19]
[44] France (08.10.03 15:52)
В таком случае, скажу тебе по секрету, админ в орокле тоже может посмотреть/изменить любые данные и даже совсем грохнуть базу.
Так что, не будет тебе щастья от оракла. :))
См. вот сюда:
[37] MsGuns © (06.10.03 14:26)
Привел какой-то АДАБАС, который шифрует данные, но я уверен, что даже в нем админ может грохнуть всю базу, несмотря ни на какие шифры.
Значит, никакого выхода нет, гадкий админ все равно может все прибить, о боже, какая низость с его стороны, пора совсем завязывать с программированием.
Danilka (2003-10-08 16:07:00) [20]
[44] France (08.10.03 15:52)
В таком случае, скажу тебе по секрету, админ в орокле тоже может посмотреть/изменить любые данные и даже совсем грохнуть базу.
Так что, не будет тебе щастья от оракла. :))
См. вот сюда:
[37] MsGuns © (06.10.03 14:26)
Привел какой-то АДАБАС, который шифрует данные, но я уверен, что даже в нем админ может грохнуть всю базу, несмотря ни на какие шифры.
Значит, никакого выхода нет, гадкий админ все равно может все прибить, о боже, какая низость с его стороны, пора совсем завязывать с программированием.
| |
Страницы: 