Как спрятать от пользователя настройки
KiberGus 19 января, 2006 - 23:58
Ситуация такая. Я хочу написать программу. Она должна запускаться от обычного пользователя и шаманить с базой данных. Естествекнно она пароль от базы должна знать, а пользователь нет. Как это можно организовать? Мне пришло в голову только зашить его в саму программу и дать права на исполнение, но не на чтение. Но это не есть очень хорошо.
»
- Для комментирования войдите или зарегистрируйтесь
Зашить пароль в
Зашить пароль в программу не такая уж плохая идея....
Можно хранить пароль в отдельном файле с правами на чтение только рутом, а программу сделать сюидной (
chmod +s proga) что бы могла читать из того файла. Главное не забыть запретить пользователю изменять файл с программой. Хотя этот вариант не чуть не лучше предложенного вами...Она будет еще и
Она будет еще и под chmod'ом запускаться, а там наличие пользователя root нежелательно. Если больше ничего не придумаю, то сделаю так, тем более, что оно будет секунд за 30 собираться.
Re: Она будет еще и
Под chroot наверное?
Да, описался.
Да, описался.
Юзверь не
Юзверь не должен знать собственного поароля на вход? Интересный подход.
Все многопользовательские субд имеют собственную систему идентификации юзера, так что изобретать велосипедов надо нет. Более того многие из них (постгри, sybase например) умеют пользоваться системными логинами, группами и тп, некоторые завязаны на лдапы, памы, керберосы и прочую дребедень, позволяющую тянуть логины с сервера идентификации (с контроллера домена к примеру). Все что нужно в этом случае - завести в системе юзера и добавить его в группу mydb, например. А в базе прописать права для этой группы. А то что вы пытаетесь сделать не есть хорошо. Зашить суперпароль в систему, а потом делать надстройку над стандартной системой защиты субд... Так кстати 1С писан (руки бы поотрывать за подобное использование sa)
Вобщем ИМХО вместо изобретения велосипедов надо разобраться и юзать нативную систему защиты субд.
Тогда надо
Тогда надо использовать такую СУБД которая позволяет давать права на отдельные записи в таблицах. Я программу пишу как раз для того, чтобы разобраться как все надо делать. Если не сложно, можете написать названия, по поводу которых читать?
Дык а на какую
Дык а на какую субд?
Что касается постгри, мне стандартной доки вполне хватает, она у них в
/usr/share/doc/post... ставится при USE="doc ...", 5 способов аутдентификации (керберос и пам входят). У майэскуэль помнится была нетрадиционная система защиты, без бутылки не разберешься, как сейчас не знаю (давно не пользовал), думаю доки у них не хуже чем у постгри. Один минус все на инглише. Где найти русские не интересовался за ненадобностью. Для мелких настольных проектов можно вообще какой нить sqllite прикрутить
Ну пока я
Ну пока я собирался использовать mysql. Там защита на уровне таблиц (по карйней мере я пока умею работать только с такой защитой). Ставить что-то простое я не хочу.
Пишу я банковскую систему для игры. В этом (вернее в декабре прошлого) году неплохо отработала очень простая реализация, а к следующему хочу сделать нормально. Для меня же главная цель научиться писать правильно.
Защита защите
Защита защите рознь, модель мускула не особо распространена. Более классический она реализована в sybase или postgresql.
Ежели на поиграться - бери постгри. Очень интересная вещь, наворотов много больше чем у мускуля. Для начала можешь поставить pgadmin3 (графическая тузла для постгри) очень помогает разобраться. Для массовых правок - любимая текстодробилка, авк,psql, make и немного фантазии.
Русские доки ищи в нете, на мускуль точно есть.
Я тут подумал,
Я тут подумал, средствами СУБД тут защититься не получится. Просто эта программа должна иметь право выполнять определенные действия. А вот пользователь должен работать с СУБД исключительно через эту программу.
В результате решил использовать chrootssh
http://chrootssh.sourceforge.net/index.php
Причем отключить там поддержку sftp. Т.к. в чруте не будет ни баша ни cat, а только набор моих утилит, то просмотреть файл конфигурации он не сможет.
? <ИМХО> это
?
<ИМХО>
это разные вещи. Если речь идет о написании клиента к субд -это одно, локальные системные функции программка может исполнять либо от имени пользователя либо от имени рута через sudo (зачем?, как быть с виндами?). Запросы пересылаются к удаленному серверу БД на определенный порт, ответы возвращаются к клиенту. Права исполнять чего бы то ни было на сервере бд при этом не нужны.
Если речь идет о предоставлении удаленной консоли, ну тогда действительно ssh, и для тех кто очень боится - chroot. Это всего лишь способ размещения клиента, никакого отношения к защите баз данных это не имеет.
ЗЫ
Ежели отключить фтп, то каким макаром юзверь результаты работы с сервака заберет?
Есть еще вариант работать с субд через веб интерфейс через https.