![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
И почему не Джумла?:)
...он с любопытством ковырялся в пойманном проклятии, всё ещё колебавшемся на кончике палочки, вытягивал пальцами красные искры и отщёлкивал их в стороны, разбирая заклинание на части, словно детскую игрушку-конструктор...
Домен зареган 1 ноября 2013.
Сайт залит на хостинг 6 ноября 2013.
8 ноября 2013 в него добавлено минимум три закладки формата "приход с запросом POST на определённый URI сотворяет и исполняет PHP код" и одну формата "создаём ежеминутное задание в кронтаб, исполняющее созданный 1.sh который творит бинарные файлы libworker.so и /usr/bin/host, причём их содержимое зависит от архитектуры. :)
В 2014 и в 2015 годах, явно по случаю продления домена, админы хостинга просыпались и обращали внимание, что сайт что-то делает не то. На тему чего его блокировали и частично очищали от говна (но часть говна, особенно бинарник /usr/bin/host, жила неизменно).
Cледы этого - в тикет-системе хостера, с датами блокировок
24 января (неизвестно, правда, каким кодом, и мне откровенно лень искать) в корне сайта было нагенерено около 80 тысяч статических .html, представляющих собой фишинговые страницы, имитирующие страницы магазинов японоязычного содержания, при этом сделанные как "якобы вы сюда пришли с результатов поиска в Yahoo", но формочки при этом отправляют POST с интересными данными на разные странные адреса.
25 января хостер написал ругательство - исправьте в течение недели а то заблокируем.
Примерно вчера заблокировали.
Иными словами, в течение 2 с лишним лет сайт не столько служил его заказчику, сколько помогал зарабтывать бабло целой пачке злоумышленников.
Сегодня я всего лишь копаюсь в коде этого угробища.
no subject
В итоге у владельца в личном кабинете ссылки на штук пять-восемь (лень считать, сколько именно) списков вида "объявления, готовые к публикации", "объявления, которые требуется оплатить", "объявления, по которым требуется уточнение".
Что веселее, у оператора таких больше десятка.
В выпуске раз в неделю порядка 10 тысяч объявлений. Ну, допустим, процентов 20 подаются через сайт, но перспектива - ближе к 100, народ постепенно сдвигается в интернет. В основном в последние два дня перед закрытием приема в выпуск. На обработку одного объявления уходит в среднем штук семь запросов (4, кажется, минимум). Из них чуть больше половины - операторские, т.е. с подсчетом актуального состояния подготовительной информации по всем пользователям.
Немножко не то, что ты описал, по требованиям к ресурсам, ты не находишь?
Не, в принципе можно сделать конструкцию, где процесс, работающий от имени юзера, вообще не будет ходить к базе, и будет написан на C, чтобы минимизировать время на инициализацию. А синхронизацию между основной базой, серьезной, и индивидуальными базами юзеров (эти хоть plain text) делать отдельным демоном. Тогда можно будет уложиться примерно в те же ресурсы по железу. Зато потребности в разработчиках на порядок выше.
То есть я за такое вообще не возьмусь ни за какие деньги, мне нервы дороже.
no subject
Ну так у меня не было той дополнительной информации, что ты сейчас выдал. То, что я написал - по результатам БЕГЛОГО осмотра сайта, его структуры и его ЗАЯВЛЕННЫХ на нём самом ТТХ.
Там workflow тот еще. Даже с точки зрения владельца объявления. Ой, мне поправить, ой нет, я платно не готов, давайте я изменю так, чтобы бесплатно проходило, и т.п.
В итоге у владельца в личном кабинете ссылки на штук пять-восемь (лень считать, сколько именно) списков вида "объявления, готовые к публикации", "объявления, которые требуется оплатить", "объявления, по которым требуется уточнение".
Это не меняет сути нарисованной мной схемы.
Усложняет генератор задания от пользователя в очередь - да.
Требует выделения пользователю "песочницы" доступных только ему и root данных со сложной структурой обработки оных - да. Про демона и про висящие в памяти процесы юзеров (опять ты рисуешь этот ужас своих каких-то личных снов) - нет, ты бредишь.
НЕ требует такая постановка задачи обязательного перехода к парадигме "код, исполняемый для действий пользователя с информацией в личном кабинете пользователя, следует исполнять с правами root и с разрешением править всю базу, и только отсутствие ошибок и тщательное программирование каждой ветки защищает от пиздеца", в рамках которой ты приступил к работе ИЗНАЧАЛЬНО. :)
То есть - в "моей" схеме от дыр класса "пользователь сумел править ему недозволенное" защищает сама логика "пользователь не запускает кода, которому что-то позволено лишнее".
А в "твоей" схеме - "всё работает от рута, и малейшая неаккуратность в коде - поле для эксплойта, в какой бы части кода эта неаккуратность ни располагалась".
Подчеркну - да, всегда есть тонкости хотя бы с той же оплатой, подтверждение которой наверняка может приходить с трёх, а то и более сторон, а задержки в обработке заданий очереди критичны. Это усложнит и обработчик заданий в очереди.
То есть сложность распределена по разному.
Тебе проще "ни за какие деньги" не строить песочницы, а работать "чтоб всегда под рутом" - верю. Это как раз универсальная парадигма современного мира "всем написанным идиотами пользовательским программам в винде зачем-то вдруг требуются права администратора", и она привычна и всосана со спермой Билла Гейтса всем пользовательским населением сети. :)
И так, "под рутом", творить ВСЕМ проще, быстрее, спокойнее.
Хуяк - и в продакшн.
И потому получается то, о чём я написал в посте.
Массово.
no subject
Я не сказал, что в твоей парадигме эту задачу решить нелья. Я сказал, что решить ее можно. Я прекрасно понимаю, как. Но ценой либо просадки по ресурсам, либо резкого удорожания разработки из-за необходимости писать сложную логику на низкоуровневом языке. Причем удорожания не по деньгам - по жизни разработчика.
И я довольно подробно изложил свою точку зрения на то, откуда берется это удорожание. Any ideas?
no subject
Я не говорил, что "мой" путь дешевле или проще.
Я не говорил, что "мой" путь не потребует от разработчика компромиссов.
Я считаю, что если бы за первые реализации http серверов брались, СОБЛЮДАЯ логику "логиненный - анонимный" (замечу - в формате лога того же апача есть инфорация о http логине, и при http авторизации она туда гарантированно попадает) и исполнение кода от соответствующих юзеров и групп - то к нынешнему моменту в качестве базы для реализации любого движка был бы не уродский апач с suexec костылями, а намного более эффективный код, в котором проблема производительности для переключения контекстов, о котором ты плачешь - была бы решена.
Пример перед глазами, реализованный как вполне живой, используемый народом продукт (пусть и не в http, а в mail) - хотя бы qmail, где нет отдельных узеров для всех "почтовых ящиков" или "посетителей", но есть хотя бы чёткое деление процессов по пользователям и по их роли в процессе обработки почты.
Я утверждаю, что завоевание мира логикой "все работаем от рута" в случае http серверов так, как они сейчас массово написаны, УБИЛО самую возможность делать НОРМАЛЬНО безопасный код.
Ты сетуешь о ресурсах разработчика, которые требуются для того, чтобы написать эффективный код в "моей" парадигме. Так в том и дело, что СЕЙЧАС огромные ресурсы разработчиков (время, жизнь) тратятся на то, чтобы разгрести именно состояние "все работаем от рута".
Фишка в том, что рынок эти затраты сейчас только подстёгивают и наслаждают.
Разрабы нагло отвечают "Чтобы исправить эти недостатки нашей CMS - заплатите нам за работу по исправлению примерно столько же, сколько платили нам за разработку". Прекрасно зная, что они могут оставить ЛЮБОЕ количество недостатков в коде - и к ним снова придёт с баблом и протянутой рукой этот заказчик.
Я это наблюдал несколько раз. Причём два случая - сознательно такие, ибо код зашифрован Zend и обфусцирован до невменяемости. Так что и не проверишь. Причём в одном случае, если суметь раззендить и посмотреть на имена файлов - видишь MODX, а не самостоятельно написанный движок. :)
no subject
Во-первых, куда могла бы деться проблема производительности для переключения контекстов, если для защиты ты полагаешься на ОС? В этом раскладе отдельный залогиненный юзер - отдельный процесс, и никак иначе. Здравствуй, задача инициализации каждого такого процесса. Дальше можно искать компромисс между количеством одновременно запущенных процессов и временем на инициализацию вновь запущенного, но проблема уже стоит, и это - поиск ее кое-какого решения.
Во-вторых, должен заметить, что когда брались за первые реализации HTTP-северов, аутентификации в HTTP еще и в проекте не было. Ну, что вменяемых до сих пор никто не поддерживает, да и нету их нифига, это уже как раз исторический вопрос. Пользовались бы HTTP аутентификацией - были бы и поддерживались бы.
qmail я, знаешь ли, ставил. Снес довольно быстро, и знаешь, почему? В его модели невозможно проанализировать содержимое письма на этапе SMTP-диалога. В результате не существует корректного работоспособного способа оповестить отправителя о том, что мы отказываемся принять это письмо на основании анализа его содержания. Ну, там и других тараканов хватает. Логика анализа служебной информации у него тоже, мягко говоря, не на высоте. Короче, пока на него реальных задач не вешают, он быстрый и секьюрный.
А разделение ролей по задачам как у qmail (именно как у qmail, а не как у твоей идеи) - ну, так его любой современный движок умеет. Вот рут, от него работает только accept(2) на 80 порту, вот владелец кода, который апгрейдит код сайта, а вот пользователь, от которого этот код выполняется. К сожалению, не то чтобы прям вот все стандартные инструкции заточены под разделение второго и третьего, но уже многие, чесслово. (Тут есть засада - не всегда у разработчика кода сайта есть два логина туда, где он этот код тестирует. В результате он вынужден разрабатывать, совместив этих юзеров.)
Про твою идею я тебе рассказываю примерно то же самое. Что годится она для достаточно узкого класса задач, далеко не покрывающего реальные потребности веб-сервисов. В нем она секьюрная, хотя далеко не быстрая. На глаз - практически применима для сайта с примитивным workflow и частотой запросов единицы в минуту. Ну, малые десятки на непродолжительном пике. Практически - это значит, что код, реализующий необходимую функциональность сайта, все же будет своевременно написан. Теоретически можно сделать лучше, но практически никто этого не потянет.
И кстати, рута-то она реально требует. И далеко не только для того, чтобы занять 80-й порт. Те же описываемые тобой движки работают от одного юзера, но не от рута, как ты тут пишешь. А при нормальном контроле за разработчиками - и не от владельца кода. А твоя идея требует использования рутовых полномочий движком. В полный рост и со сложной логикой. Упс... Дополнительный вектор атаки... Безопасность, говоришь...
Да, конечно, если это выделенная машина под сервер, то возможность испортить любые данные в базе с точки зрения работоспособности сервиса мало отличается от возможности испортить вообще что угодно в системе. А вот с точки зрения восстановления испорченного - ой, отличается... Потому что хотя бы бэкапы взломщик тронуть не сможет - прав не хватит. А при грамотном подходе - и логи тоже.
no subject
А вот telnet/ssh уже была. Мыль понятна? Я говорю о том, что http реализовывать стали БЕЗ авторизации, хотя опыт разницы в работе "без авторизации" и "с авторизацией" уже вроде как был, хехе. :)
А твоя идея требует использования рутовых полномочий движком.
Нет. Она не требует этого.
Ты невнимательно прочитал.
В работающем сайте "по моей идее" настоящий, операционной системы рут не нужен на исполнение кода сайта нигде.
Чтоб тебя не пугать слово "рут" - заменим его на admin
Рут нужен вебсерверу, да. "Идеальный" вебсервер по "моей" концепции на машине с unix узерами
admin_1 nobody_1 user_1_1 user_1_2 для админа, анонима и узеров 1 сайта,
admin_2 nobody_2 user_2_1 user_2_2 для админа, анонима и узеров 2 сайта,
должен "развести" посетителей в код, исполняемый от соответствующих unix пользователей, причём структура на FS может быть примерно такой:
/www/ +- admin_1/ +- user_1_1/ +- user_1_2/ +- nobody_1/ +- site_1_code/ +- admin_2 +- user_2_1 +- user_2_2 +- nobody_2 +- site_2_code/admin_1 работает в своём чруте и имеет доступ к каталогам узеров.
admin_2 работает в своём чруте и имеет доступ к каталогам узеров.
Потому что хотя бы бэкапы взломщик тронуть не сможет - прав не хватит.
О боже, я разговариваю с человеком, который считает допустимой логику "бекап в пределах одного сервера" 8-О.
no subject
Ну, ssh тоже еще не было. Но вообще-то тут правильная мысль не та, что HTTP начали без авторизации, а та, что HTTP стали применять не по назначению. Видишь ли, HTTP изначально вообще не был предназначен для иной раздачи, кроме публичной. PUT в нем заложили плюс-минус изначально, но он оказался мертворожденным. По сю пору его почти никто не умеет. Ну, DAV-клиенты вроде научились. Без году неделя... Про авторизацию-то сразу подумали, но сразу и решили, что не надо ее закладывать в протокол, кроме кода 401. Есть мнение, что правильно решили-то...
> Чтоб тебя не пугать слово "рут" - заменим его на admin
Ты сам сказал про sudo.
Ну да, при наличии ACL (что уже несколько выбивается за юниксовую модель прав, ну ладно) твоя схема с некоторыми изменениями годится. В смысле, as is она тоже годится, но для совсем уж тривиальных задач. А как только у тебя на сайте появляется две различных роли стаффа, так сразу подавай ACL. Потому что роль реализуется группой, а в юниксовой модели as is группа у файла одна. Ну, к счастью, процесс может разрешить доступ к группе, которой у него своей нет (иначе б облом). Если есть ACL. То есть возможность использовать твою модель у нас намного моложе, чем юникс и HTTP. ACL у нас появились, кажется, в начале 2000-х, хорошо если не в середине первой декады. А во FreeBSD даже и не знаю, есть ли вообще.
В общем, да, без рута можно обойтись. Правда, теперь уже просто файл не создашь, а надо непременно развешивать на него ACL по числу ролей. На каждый. Движком. Откуда, кстати, брать список ACL под данный конкретный файл - тот еще вопрос... Нет, понятно, что из конфига сайта. Только... Там будет уже настолько сложная логика, что это будет уже код. И рутовые права при апдейте этого конфига, поскольку доступ к файлу может поменять либо его владелец, либо рут, а у тебя будет дофига файлов с разными владельцами. Ты все еще полагаешь, что это безопаснее, чем то, что есть? Really?
P.S. За бэкапы. Я реалист. Не всегда можно сделать, как у меня, когда база бэкапится на другую машину раз в час. Более вероятно, что бэкап за пределы хоста удастся делать довольно редко, а еще более вероятно - что такой бэкап будет максимум один, и всей системы целиком, хостеры если предоставляют бэкап, то только такого рода. А база-то немаленькая, в офис в Таганроге ее раз в час не особо забэкапишь. А там еще картинки, и вскоре их тоже станет немало.
no subject
Unix системы в целом НЕ ушли от логики "тщательно разграничиваем пользователей". Несмотря на то, что это - по твоему - требует огромных затрат жизни и ресурсов разработчиков.
А виндовые системы, несмотря на появление (с windows NT 4 начиная) внятных средств деления прав пользователей и ACL на FS - массово живут в состоянии "все работаем из под админа, потому что очередная софтина так потребовала". Правда, поверх этой логики наворочены UAC, "переспрашивания - действительно ли пользователь хочет этого?" и тому подобная хуита, которая совершенн оничего по сути своей не меняет.
И сравни результат по безопасности, вирусам и прочая для этих двух групп систем :)
Примени не свои рассуждения, а ЭТОТ ОПЫТ - но к http протоколу. Что получится?
no subject
Виндовые системы - удачный пример в смысле "исторически сложилось", но неудачный - в смысле "зато производительность приемлемая". Она у них что так, что эдак неприемлемая. Иначе мы бы с тобой тут не говорили о проблемах сайтов на базе юниксов.
Задачи-то другие, блин. С другими требованиями к производительности. Это я на домашнем сервере могу спокойно отнестись к тому, что locate работает 2 с половиной минуты, и на ноутбуке больше секунды (не updatedb! locate!). Напрягает, но не очень сильно. А аналогичное действие на веб-сервере должно занимать не больше 1/100 секунды. Иначе оно просто не сможет решить поставленную задачу. На том, что оно занимало больше, погорел communiware. Вот, опыт.
Это mlocate, it indexes all the filesystem, but results of a search will only include files that the user running locate has access to. Безопасность...
no subject
А как же "линукс способен заменить windows на десктопе", "микрософт офису есть реальные бесплатные альтернативы"?
Машинка, где w | wc -l давала бы результат около 30 - у меня лично давным давно стояла на Смольной на ip 213.134.196.7, и была 486SLC2-40/4M RAM/(не помню сколько размер харда), 10 Мбит сетевуха. Служила Primary DNS сервером для кучи доменов, а также для некоторого количества народу маленьким развлечением в шелле, без графики. sudo был только у меня. :)
Железка сейчас не работает, так как на ней умер onboard контроллер харда. Иначе я бы, пожалуй, постарался на ней поднять что-нибудь просто из принципа.
no subject
Но задачи действительно разные, что тебя удивляет? В смысле, разные не между виндой и линуксом, а между нормальной юзерской работой и работой нагруженного веб-сервера.
30 - это неинтересно. Интересно несколько сотен, и не развлечения в шелле, а хотя бы 20 запросов в секунду. На всех. Ок, без UI. Нет, не "Hello, world" на C. "Hello, world" на ruby в качестве теста кое-как сгодится, только с подгрузкой штук пяти хотя бы модулей. Тут как раз - либо много памяти, если много процессов одновременно, либо небыстрая инициализация.
no subject
Э. Ты правда считаешь, что неинтересно на машинке ЭТОГО класса?
Вообще-то это, напоминаю, процессор в корпусе 386SX, внешней шиной 20 МГц, внутренним кешем 1к и ядром, работающих на 40МГц. И 16-битная шина внешняя с 4-мя SIMM 40pin на ней. И ISA Only для периферии.
Я понимаю, что "эпоха сменилась", и "языки теперь почти только интерпретируемые и скриптовые", и "что такое 4 мегабайта?"
Для полноты картины - на какой конфигурации вертится твой проект?
no subject
zsh% free total used free shared buffers cached Mem: 49961176 258924 49702252 0 0 0 -/+ buffers/cache: 258924 49702252 Swap: 0 0 0Intel(R) Xeon(R) CPU E5430 @ 2.66GHz, 8-ядерный, но это виртуалка, и я там сильно не один.
Лимиты выставлены довольно приличные, в нынешней конфигурации близко не подходил. Но при заливке свежего выпуска и последующем набеге читателей на свежий выпуск проседает конкретно, до писем от яндекс-метрики, что за 10 секунд сайт не ответил. То есть фактического запаса-то нет, хотя формально вроде как есть, и большой.
А вот если начать делать по процессу на юзера, то уже придется заботиться о том, чтобы не упереться в лимит по количеству процессов. Впрочем, если писать не на чистом C, то сперва упремся в фактический лимит по памяти. В лимит по процессам - это если процессы почти не занимают память...
no subject
Вот вот.
Я очень хорошо помню, как в процессе секспериментов с видеотрансляциями обнаружил, что видеосервера равной вроде функциональности могут кушать от 14К до 200М на 1 посетителя... :)
no subject
no subject
>результат по безопасности, вирусам
Линуксовых десктопов не бывает, там нет вирусов. На виндовых веб-серверах веб-зараза не водится, там для нее слишком некомфортно.