ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] Авторизация Re:



In <Pine.LNX.4.03.9901281146490.6372-100000@brass.fe.msk.ru> Victor B Wagner 
(vitus@ice.ru) wrote:
VW> On Mon, 25 Jan 1999, Khimenko Victor wrote:

>> По моему спор идет по принципу "в огороде бузина, а в Киеве дядька". По-моему
>> исходно речь шла не об авторизации пользователя вообще ! Как я понял проблема
>> (с которой я также столкнулся) проще всего пояснить на примере: пусть у нас
>> есть, скажем, записная книжка (GuestBook) в базе данных, которая принадлежит
>> какому-либо пользователю. Обращение к ней идет через PHP или через mod_perl 
>--
>> фиолетово. При этом пользователь, который делает записи в GuestBook'е вообще
>> никаких паролей знать не должен ! Не нужно ему это ! Однако чего нам бы не
>> хотелось, так это того, чтобы наши соседи по web-server'у могли после взгляда
>> на исходники скрипта весь GuestBook испохадить напрямую, не проходя через
>> соответствущий скрипт и не оставляя записей в log'ах Apache'а. Я не умею 
>этого
>> делать ни с использованием PHP, ни с использованием mod_perl'а без
>> использования внешних программ, да и с ними добиться сколько нибудь приличной
>> защиты сложно -- разве что при использовании suexec'а и запрете mod_perl'а и
>> PHP, да и то не факт... Авторизация через SQL -- это хорошо (Да мало ли через
>> что можно безопасно авторизоваться ? При использовании PHP можно и 
>imap-сервер
>> к делу приспособить, например :-), но речь-то шла не о том...

VW> По-моему, идеальным языком для решения поставленной задачи является Tcl.
VW> В нем есть развитая система Safe Interpreter'ов и можно реализовать это
VW> так:

VW> При запуске скрипта поднимается сначала trusted interpreter, который
VW> проверяет владельца скрипта и подгружает модуль для коннекта к БД и
VW> cgi-lib. Вместо команды oralogon или pg_connect он экспортирует в safe
VW> interpreter свою процедуру, которая коннектится всегда под именем
VW> владельца скрипта. Как они с базой при этом договорятся - вопрос
VW> отдельный. Важно что пользователь доступа к этому коду не имеет. Кстати,
VW> и файловые операции он имеет только те, которые trusted interpreter
VW> экспортировал. То есть можно проверять что угодно, например owner id match

VW> Это все можно прописать в виде скрипта, который будет в пользовательских
VW> скриптах писаться в #!/ вместо реального интерпретатора (только надо
VW> позаботиться о том, чтобы пользователю туда не дали tclsh написать.

VW> Как это делать в случае mod_neowebscript - не знаю, но полагаю, что в
VW> NeoSoft man n interp читали.

С mod_neowebscript я дальше его лицензии на продвинулся :-)) Она требует покупки
этого всего при использовании на сервере с поддержкой SSL и запрещает мне
распространять скомпилированный бинарник -- ну и пусть его кто-нибудь другой
покупает. Вот только меня заинтересовала фраза: "важно что пользователь доступа
к этому коду не имеет". То есть эта вещь запускается отдельным процессом
(иначе бы пользователь Apache и, стало быть, и все остальные, имели бы доступ
к коду или к псевдокоду :-) -- как оно взаимодействует с Apache'м ?

P.S. Можно использовать FastCGI, наверное...





 




Copyright © Lexa Software, 1996-2009.