Новые уязвимости в lighttpd

А почему никто не говорит о таких опаснейших уязвимостях как: "Неопределенность мышления злоумышленника" и "Выпивший админ в серверной"?

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

thttpd сосет -- достаточно посмотреть как он работает с файлами.
А nginx.. кто сумел понят его код, пусть бросит в меня камень.

>thttpd сосет -- достаточно посмотреть как он работает с файлами.

Ага.. ага.. ну а почему его sourceforge узает как основу??

>А nginx.. кто сумел понят его код, пусть бросит в меня камень.

Насчет nginx согласен, бредовый сервер.

ЗЫ Апач рулид..!

Zulu не нужно так писать, а то складывается мнение о вас ... несколько странное. Каждая программа хороша на своем месте (для своей задачи), для статики и 1-2 пользователей с аутентификацией лучше thttpd пока не нашел. lighttpd обновлять задолбаешься, nginx - да, пока не разобрался, возможно тоже хорош.

код достаточно понятен - просто за счёт архитектуры и "высокой оптимизированности" требует некоторой адаптации мышления привыкшего к классической архитектуре (префорк/тред-на-соединение)
Начать можно с http://www.riceonfire.org/emiller/nginx-modules-guide.html

>>thttpd сосет -- достаточно посмотреть как он работает с файлами.
>Ага.. ага.. ну а почему его sourceforge узает как основу??
не знают про nginx ?

>>А nginx.. кто сумел понят его код, пусть бросит в меня камень.
>Насчет nginx согласен, бредовый сервер.
В чём его бредовость ?

>ЗЫ Апач рулид..
и как он "рулид", а главное чем, на большой нагрузке, 1000+ одновременных соединений например ? Его уже научили перечитывать конфиги / обновляться без потери соединений ? особенно при изменении кода модулей ?

>А почему никто не говорит о таких опаснейших уязвимостях как: "Неопределенность мышления злоумышленника" и "Выпивший админ в серверной"?

Потому что это не характеристики софта как такового. Пьяный админ представляет собой опасность даже при отсутствии софта.

лайттпд шустрый сцуко очень. и даже теоретические уязвимости тут не помеха.

sourceforge уже давно использует lighttpd, так же как и youtube

Connected to sourceforge.net.
Escape character is '^]'.
HEAD / HTTP/1.1
Host: sourceforge.net

HTTP/1.1 200 OK
X-Powered-By: PHP/5.2.1
X-SFX-Webhead: sf-web21
X-SFX-Revision: release_20070606
ETag: "jpd-318408890.24788"
Content-type: text/html
Date: Sat, 21 Jul 2007 11:55:21 GMT
Server: lighttpd/1.4.15


Совершенно типичный thttpd, правда?

> Zulu не нужно так писать, а то складывается мнение о вас ... несколько странное

Угу, а я и есть странный

> для статики и 1-2 пользователей с аутентификацией лучше thttpd пока не нашел.

Ничего страшного, это потому что плохо искали. Поищите еще.

> lighttpd обновлять задолбаешься

Да, и выкиньте слакварь -- есть дистрибуивы, где ментейнеры занимаются обновлением пакетов по безопасности.

> код достаточно понятен - просто за счёт архитектуры и "высокой оптимизированности" требует некоторой адаптации мышления привыкшего к классической архитектуре (префорк/тред-на-соединение)

Я слава богу разные исходники читал. Но nginx -- это просто шедевр, начиная от его системы сборки (закат солнца вручную, take one) и заканчивая потрохами. lighttpd тоже использует поллинг, но его код читается, в отличие от.

Мдя, будем обновляцо

> Я слава богу разные исходники читал. Но nginx -- это просто шедевр, начиная от его системы сборки (закат солнца вручную, take one) и заканчивая потрохами. lighttpd тоже использует поллинг, но его код читается, в отличие от.

У nginx много уникальных возможностей - встроенный mod_rewrite, load balancing, кеширование через memcached

>> Я слава богу разные исходники читал. Но nginx -- это просто шедевр, начиная от его системы сборки (закат солнца вручную, take one) и заканчивая потрохами. lighttpd тоже использует поллинг, но его код читается, в отличие от.

Игорь как то объяснял почему не используется использует autotools - http://www.lexa.ru/apache-talk/msg09306.html

про код - вполне нормальный. эффективный. что именно тебе не нравится ?
то что ты в нём не смог разобраться - ещё не повод утверждать что он нечитаем.

зулу, тут недавно ветку про новый нгинкс читал года 2005, ты там тоже самое писал. наверно тогда твоё чтение когда завершилось?

> У nginx много уникальных возможностей - встроенный mod_rewrite, load balancing, кеширование через memcached

Это еще не все, один embeded perl чего стоит, некоторые умудряются сайт написать целиком на nginx :). Правда, надо тут учитывать что пока работает этот перл рабочий процесс, по понятным причинам, долго работать не должен.

> Это еще не все, один embeded perl чего стоит

В lighttpd есть embedded lua. =)

> некоторые умудряются сайт написать целиком на nginx

Пороть. Потом тыкать харей в FCGI/SCGI. :P

> У nginx много уникальных возможностей - встроенный mod_rewrite, load balancing, кеширование через memcached

Уникальных? :) В lighttpd всё это было испокон веков.

А вообще, пока nginx не научится самостоятельно (пере)запускать FactCGI-шные процессы, он так и будет у всех ассоциироваться с «500 Internal Server Error». :P

ну не 500 а 502 - bad gateway  :)

впрочем, он НИКОГДА и не научится. не его это дело мэнеджить fastcgi процессы.
это даже не смешно - ставить вебсервер на машину где вертится fascgi сервер только для того чтобы он его (пере)запускал, сам понимаешь это далеко не всегда один и тот же сервер.

к слову сказать - про fastcgi. anight выложил набор своих патчей к пхп как раз для нормально реализации этого функционала в оном: http://php-fpm.anight.org/

>> Уникальных? :) В lighttpd всё это было испокон веков.
Можно сказать что и в nginx испокон веков. Впрочем по функционалу они очень схожи, за редким исключением. Но на части задач nginx быстрее / экономичнее в использовании памяти-процессора.
Так что тут выбор сервера скорее просто вопрос личных предпочтений :)

Гг, RTFM.

http://trac.lighttpd.net/trac/wiki/Docs

Конкретно на предмет
mod_rewrite - Rewrite
mod_proxy - Proxy (с load balancing)
mod_mem_cache - caches static files in memory for faster serving
mod_cache - Web Accelerating Cache

Нет, я недавно сделал попытку перечитать еще раз. Первая же строчка, попавшаяся мне на глаза -- разбор HTTP request.

... a[0]=="G" && a[1]=="E" && a[2]=="T" ...

Автор не изменился 8))))

> то что ты в нём не смог разобраться - ещё не повод утверждать что он нечитаем.

Еще как повод. Я не программист, но при этом умею нормально читать. Если я не понимаю код, значит он написан как минимум специфично и понимает его гораздо меньшее число человек, чем хотелось бы.

>> некоторые умудряются сайт написать целиком на nginx >Пороть. Потом тыкать харей в FCGI/SCGI. :P

Это не руководство к действию, это демонстрация возможностей nginx. Есть миллионы примеров когда nginx незаменим, читайте рассылку. Еслиб у nginx были полноценные аналоги то Сысоев бы не стал его писать.

> ... a[0]=="G" && a[1]=="E" && a[2]=="T" ...

Упалъ! :D

Я даже догадываюсь, чем автор мотивировал отказ от strcmp: «Типо мы цикл развернули и всё будет ваще быстрее работать!» :)

> Автор не изменился 8))))

И как бы ты предложил сделать эту проверку?

>Я не программист, но при этом умею нормально читать. Если я не понимаю код

Если ты не программист то тогда зачем в код лезешь и зачем жалуешься что ты его не понимаешь? Зато посмотри конфиг nginx, не думаю что тебе будет что-то не понятно.

А типа медленнее будет работать? почитай рассылку, там про это, кстати, было написано.

> А типа медленнее будет работать?

Premature optimization is the root of all evil, anonymous.

> почитай рассылку, там про это, кстати, было написано

Можно ссылку?

>> Еще как повод. Я не программист, но при этом умею нормально читать. Если я не понимаю код, значит он написан как минимум специфично и понимает его гораздо меньшее число человек, чем хотелось бы.

Да, он написан специфично, но ХОРОШО. Если ты удосужишься разобраться - то обнаружишь что качество кода и использованных решений более чем хорошее.

> ... a[0]=="G" && a[1]=="E" && a[2]=="T" ...

> Автор не изменился 8))))

Гм, друзья, судя по исходникам версии 0.6.4, автор понял, что
вручную побайтово сравнивать строки несколько неудобно. Но
выводы из этого сделал своеобразные. :) И теперь использует свои
труъ-высокооэффективные версии strncmp.

Я не в силах удержаться, чтобы не запостить этот шедевр, господа!

/* nginx-0.6.4/src/http/ngx_http_parse.c */

#if (NGX_HAVE_LITTLE_ENDIAN && NGX_HAVE_NONALIGNED)

#define ngx_str3_cmp(m, c0, c1, c2, c3)                                       \
    *(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0)

#define ngx_str3Ocmp(m, c0, c1, c2, c3)                                       \
    *(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0)

< тут идут макросы ngx_strncmp для n = 4..8, поскипано >

#define ngx_str9cmp(m, c0, c1, c2, c3, c4, c5, c6, c7, c8)                    \
    *(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0)             \
        && ((uint32_t *) m)[1] == ((c7 << 24) | (c6 << 16) | (c5 << 8) | c4)  \
        && m[8] == c8

#else /* !(NGX_HAVE_LITTLE_ENDIAN && NGX_HAVE_NONALIGNED) */

#define ngx_str3_cmp(m, c0, c1, c2, c3)                                       \
    m[0] == c0 && m[1] == c1 && m[2] == c2

#define ngx_str3Ocmp(m, c0, c1, c2, c3)                                       \
    m[0] == c0 && m[2] == c2 && m[3] == c3

< поскипано >

#define ngx_str9cmp(m, c0, c1, c2, c3, c4, c5, c6, c7, c8)                    \
    m[0] == c0 && m[1] == c1 && m[2] == c2 && m[3] == c3                      \
        && m[4] == c4 && m[5] == c5 && m[6] == c6 && m[7] == c7 && m[8] == c8

#endif

По-моему, коллеги, диагноз очевиден. :-|

>Premature optimization is the root of all evil
а почему ты решил что это Premature ?

> Гм, друзья, судя по исходникам версии 0.6.4, автор понял, что вручную побайтово сравнивать строки несколько неудобно. Но выводы из этого сделал своеобразные. :) И теперь использует свои труъ-высокооэффективные версии strncmp.
> По-моему, коллеги, диагноз очевиден. :-|
Именно - nginx при той же и выше скорости работы более экономичен к памяти / процессору чем lighttpd.

> а почему ты решил что это Premature?

Ладно. Жду ссылку на подробный отчёт автора об использовании профайлера и выигранных процентах производительности. :P

К тому же, функция strncmp обычно и так оптимизирована до предела и обычно инлайнится. На x86, к примеру, strncmp сводится к repz cmpsb. Сысоевский же вариант компилируется в три пары cmpb-jne, и это имхо будет работать НУ НИКАК НЕ БЫСТРЕЕ.

> nginx при той же и выше скорости работы более экономичен к памяти / процессору чем lighttpd

Ссылка на результаты тестов? А то у меня свежезапущенный lighttpd ест ~2M памяти, а nginx - ~8M. :P

> ну не 500 а 502 - bad gateway :)

Вспомнил! 504 Gateway Timeout. Визитная карточка nginx, впору помещать на главную страницу офсайта. :)

Вполне нормальный код. Кстати, автор nginix работает в Rambler'e где знаете ли высокая нагрузка и подход к производительности/читаемости кода наверняка другой.

> Кстати, автор nginix работает в Rambler'e где знаете ли высокая нагрузка

Что, прям больше, чем на youtube и sourceforge? :P

> На x86, к примеру, strncmp сводится к repz cmpsb.

Он работает не тока на x86. Кроме претензий к стилю программирования который неустраивает лично тебя ты ничего больше предъявить не можешь? Так и запишем: "отличный вебсервер со спорными моментами в исходниках". А за профайлинг не бойся, он делался.

>Ссылка на результаты тестов? А то у меня свежезапущенный lighttpd ест ~2M памяти, а nginx - ~8M. :P

Не знаю как ты добился 8M, у меня с десятком виртхостов resident set size 3404KB, 808shared и это при limit_zone mainzone $binary_remote_addr 10m; в конфиге, nginx version: nginx/0.6.4

больше не больше
но в http://googleonlinesecurity.blogspot.com/2007/06/web-server-software-and-malw... его почемуто нет. а nginx есть.

на неткрафте правда результат другой :)
http://survey.netcraft.com/Reports/200705/byserver/index.html

про сравнения производительности - спроси у гугла, если не горазд сам проверить.
оценивать параметры сервера по количеству занимаемой памяти сразу после старта - как то мягко говоря странно.

Что ты вообще доказать хочешь ? То что Сысоев пишет плохой код ?
это не так. то что ты не можешь в нём разобраться или тебе кажется что используемые им решения менее интересны чем библиотечные - крестиццо надо :) Впрочем если этот вопрос тебя действительно интересует - спроси в мэйл листе nginx, благо он рускоязычный. Я думаю ответят и объяснят чем что вызвано.

Или то что lighty лучше чем nginx ? Это не так. Они примерно равнозначны по всем параметрам. Кто то в чём то лучше, в чём то хуже. Но непринципиально.

502 / 504 - это вообще непричём. Почему веб сервер не должен имеет отношения к запуску fastcgi - я тебе уже вроже рассказал. Как впрочем и к работе апача на бакенде.

>> Кстати, автор nginix работает в Rambler'e где знаете ли высокая нагрузка

> Что, прям больше, чем на youtube и sourceforge? :P

Еро-сенин, ты что не сходил сегодня посрать, так решил тут отметиться? =)

Или осилил только лайттпд и теперь вместе с Зулу боишься разобраться с настройкой еще одного веб-сервера? :)

Тут можно спорить и приводить разные сурсефорже и т.п. Но я прекрасно помню как полтора года назад в мире Рельс использовали только апач и лайттпд. А сейчас ситуация изменилась с точностью до наоборот. nginx используется как стандартное решение повсеместно. Ну не смог бы он "подвинуть" этих хряков, если бы уступал им.

> А nginx.. кто сумел понят его код, пусть бросит в меня камень.

Тебе булыжник побольше или поменьше ? Вполне вменяемый там код.

> По-моему, коллеги, диагноз очевиден. :-|

Это как раз тот случай когда _такая_ оптимизация оправдана. У нас апач дох нафиг на таких нагрузках, которые более-менее переваривает nginx. До перехода мне, знаете-ли оччень нравилось наблюдать как LA сервера зашкаливало за 57.

> К тому же, функция strncmp обычно и так оптимизирована до предела и обычно инлайнится. На x86, к примеру, strncmp сводится к repz cmpsb. Сысоевский же вариант компилируется в три пары cmpb-jne, и это имхо будет работать НУ НИКАК НЕ БЫСТРЕЕ.

То-то помнится все вменяемые ассемблерщики _никогда_ не использовали rep* на x86 - причём именно из-за его тормознутости.

> Вспомнил! 504 Gateway Timeout. Визитная карточка nginx, впору помещать на главную страницу офсайта. :)

А это, извините, не nginx'у а к авторам сайта. Это таймаут скриптов а не nginx'а.

проклятое решето! *побежал ставить IIS*

> Это как раз тот случай когда _такая_ оптимизация оправдана. У нас апач дох нафиг на таких нагрузках, которые более-менее переваривает nginx. До перехода мне, знаете-ли оччень нравилось наблюдать как LA сервера зашкаливало за 57.

Апач дохнет не потому, что неоптимизирован, а потому, что использует отдельный процесс или отдельную нить на каждый коннект. А nginx с lighttpd используют мультиплексирование, за счёт этого и рулят. А такие низкоуровневые микрооптимизации в лучшем случае позволят сэкономить 0.01% экономии процессорного времени. Кстати, результатов бенчмарков я так и не увидел.

> Кстати, результатов бенчмарков я так и не увидел.

У тебя бан в гугле ? nginx и lighttpd по производительности на статике идут один в один, но это сферический конь в вакууме. На динамике всё сильно зависит от того как написаны скрипты.

> У тебя бан в гугле? nginx и lighttpd по производительности на статике идут один в один, но это сферический конь в вакууме. На динамике всё сильно зависит от того как написаны скрипты.

У тебя двойка по чтению? Несколькими постами выше я интересовался бенчмарками, исследующими прирост производительности от замены strncmp на сысоевские хаки. Если прирост есть и он больше одного процента, я публично признаю себя некомпетентным ослом и больше не вякаю. Так что, ссылка будет?