extended status показывает что-то из variables, а про какую конкретно идет речь?
А причем тут WebMoney? Начнем с того, что как мне показалось, эти товарищи располагаются в другой стране.
зачем подавать в суд? надо идти в комптентные структуры и настаивать на возбуждении уголовного дела.
Никуда копать не надо. Если slow есть, то они в processlist видны, а mytop как раз его и показывает.
PS. Если память не изменяет, то slow там в минутах была когда-то...
о чем и речь, т.к. пошел уже который день, а она все чего-то ждет...
Вторая учетка нужна для того, что бы отделить полномочия скриптов, от полномочий самого пользователя... если скрипты будут выполняться с теми же самыми правами, что и лежащие файлы, то это позволит им сделать рекурсивный chmod с 777 на *
И третья учетка еще для ssh... отдельный uid для ssh обязательно нужен, т.к. если логгировать подозрительный access, то нужно разделять от кого он. И есть еще машинка, где есть и четвертая учетка, как раз для crontab. Ну а кто экономит на uid, тот делает одинаковый uid/gid для ftp/ssh/cron и еще один uid для скриптов.
Но когда речь заходить за четкое лимитирование, то под каждый исполняемый пук нужен свой uid...
По ftp он точно не поменяет, так же как и по ssh 😂
Когда все по uid/gid разносишь, то можно на файрволе еще локальном что-то настраивать... фряшный умеет матчить пакеты как по uid, так и по gid, что позволяет запретить скриптам ходить на чужие smtp... да вообще много чего рестриктед можно сделать, в частности оставить им только http/https с определенным connection rate... а то ща флудилки на php хорошие народ писать начал 😂
При этом из ssh челу разрешается юзать http, ftp, ssh и т.д. чего для нормальной жизни надо... само собой если тарифицировать, то можно и тарифицировать... а то трафик у некоторых вроде и платный на хост, а из ssh можно гигами качать, так же как и отправлять... ну а из скриптов и подавно.
У меня вон shared хостинг у народа под рисерч цели куплен, так из скриптов терабайт за месяц высасываю... ничего не тарифицируется, приятно однако. PHP там под одним uid живёт, файловый аксес рестриктед, да и фик с ними... за-то они не могут понять из скрипта какого клиента трафек сосется, в частности мои скрипты не енкриптед, но после obfuscation 😂
да пофигу на самом деле, т.к. права на их корневую диру выставлены, в моем случае, на rwx------- и овнер её сам клиент... следовательно если он по ftp на неё 777 не поставит, а он на неё по ftp поставить не сможет, то всё тип-топ...
или другой вариант... owner кто-то, а rwx только для групы, в которую занесены uid-ы фтп учетки и учетки для скриптов....😂
PS. и какая разница с какими он правами будет лить дальше... ?
Вот и я про то... одна Латынина чего стоит... на echo.msk.ru в эфире она только про Кадырова и твердила.
PS. Убийство as месть не самый лучший выход... если бы ей хотели отомстить, то поступили бы проще и резонанса было бы меньше.
IMHO никакой гарантии... надо решать вопрос глобально, а именно на уровне выполнения скрипта в теле процесса с uid/gid клиента, что само по себе снимает массу головной боли. Классическая реализация данного механизма не позволяет получить хорошей производительности, поэтому приходится идти на различные изменения ядра и самого apache, причем такие изменения дают гарантию аналогичную suexec и прочему.
У меня процессы apache меняют свой uid/gid на лету, в зависимости от того на какой vhost прилетел запрос... причем процессу это разрешается 1 раз на 1 accept... все дальнейшие попытки процесса изменить свой uid/gid блокируются и логируются. Следовательно когда реквест отработан, то процесс будет висеть с этим же uid/gid до следующего запроса... а потом ему опять позволят изменить uid/gid.
При такой security модели shared хостинга достигается МАКСИМАЛЬНАЯ производительность php на shared и гарантия аналогичная suexec. Изначально, при внесении этих изменений, предполагался один риск - получения данных из директории другого клиента... никаких процессов apache запущенных из под root нет, в отличии от всяких suPHP и прочих, которые без кернел патчей.
Более того, т.к. параноя в плане секурити никому еще не вредила, то что бы попытаться сделать аналогичный вызов функции ядра, нужно как-то скомпилироваться с нужной либой (которая не доступна) или же проанализировать полушифрованный бинарник ядра, который само собой не доступен... или проанализировать полушифрованный бинарник apache, который тоже недоступен...
Помимо кучи проверок есть еще какие-то magic key's, которые нужно знать, что бы вызов ядра не дал отлуп... на всякий случай.
Если кто-то научится получать доступ из php к области памяти с бинарем, то он получит что-то, что без ключика никак нельзя расшифровать... само собой если он утянет кернел, то тоже 😂
Вот так надо делать shared хостинг... а не на всяких там suPHP и прочих... даже без проверки "1 раз на 1 accept" это работает как часы ибо сделать вызов нет возможности, особенно из php.
Хотя делают на rfork и прочем, но это подразумевает httpd из под root и большой оверхид... в описанной мною схеме нет-у rfork и т.д.
PS. Дистрибутив в виде кернел модуля + патчи на apache2.x.
А была ли это Политковская по телефону?
Там текст, который обычно при личной встрече рассказывают, он очень объёмный...
PS. Конечно "Кавказский узел" скоро пропиарится на том, что предоставит запись разговора с покойной... если таковая есть в природе.
