The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"
Отправлено Дон Ягон, 22-Фев-20 06:22 
>> Да я и не скывался, лол.
> Ты хотел казаться. Тон в первом комментарии был соответствующий.

Это твои домыслы. В первом комментарии речь шла не про paxd и прочие костыли, чтобы хоть как-то жить с PaX. И там уже были такие "термины" как "уродство" - можешь перечитать и проверить.

> ЧТД.

Сейчас - да. В перспективе - нет. Повторяться не буду.

>> PAX MPROTECT (не включённый по-умолчанию примерно нигде, кстати) такого не позволяет, да.
> Он включён по умолчанию примерно везде, где система работает на ядре с grsecurity.

То есть примерно нигде - я всё сказал правильно. Да?
С момента закрытия кода надежды на мэйнстримный дистрибутив с grsec по-умолчанию из коробки окончательно рухнули. Зачем сравнивать нишевое решение с ОС общего назначения?

> Это решение, которое зарекомендовало себя с лучшей стороны. За ним стоят обоснованные решения разработчиков и многолетний опыт пользователей, среди которых и я.

Как это решение себя зарекомендовало, мы уже выяснили. А именно: кроме NetBSD решение не портированно примерно никуда, по-умолчанию не включено нигде у "серьёзных игроков".

>> у PAX MPROTECT всё те же per-binary исключения и выключенность по-умолчанию примерно везде.
> Определись уже, выключенность или включённость. Хотя бы в рамках одного коммента.

Выключенность, откуда у тебя вообще сомнения? Нет ни одной "серьёзной" ОС, где это включено по умолчанию. Grsec - не ОС, а набор патчей.

> Там, где он нужен, он [PAX_MPROTECT] именно лучше и именно правильнее.

История нас рассудит, посмотрим. Как по мне, смысла в костыле, пусть и довольно удачном, при наличии не ломающего стандарты решения, просто нет.

> Это не аргументы. Тебе неудобно, а мне удобно. Тебе непрактично, а мне практично. И это даже не патовая ситуация. Потому что ты теоретик, а я пользователь grsecurity с многолетним стажем его применения для личных и рабочих нужд.

Я писал и про то, почему это неудобно и почему непрактично. Про то, что можно сбросить больше привилегий и т.п., порезать доступ к fs через unveil и вот это всё.
Ты не поверишь, но я тоже года два имел десктоп с grsec ядром, и я имел опыт с grsec в продакшене (хостинг). И никаких проблем у меня не было (grsec выбирал не я, если что).
Но это не отменяет того, то проблемы есть, и если оно подходит для чего-то одного, типа хостинга, то не факт, что для другого.
Как нишевое решение grsec мне вполне понятен, но не нужно удивляться, что его не взяли в апстримный линукс и не нужно удивляться, что даже раньше почти не было "серьёзных" дистрибутивов с grsec ядром по-умолчанию.

Про pledge пока говорить рано (он ещё мб и провалится, я не ванга, будущего не знаю), но первые примеры с тем же ff и chrome выглядят неплохо.

>> Конкретно отзыв prot_exec, а не осмысленное внедрение pledge добавляется тривиально.
> Тривиально для пользователей, которым разработчики OpenBSD даже расстановку аналогов PaX-флагов решили не доверять? ;)

Ох, ну ты набросил прям как Том Сойер про забор. Понимаешь, я _рад_ что мне не надо будет расставлять PaX флаги, хорошо, что за меня это сделают авторы софта. Если бы они за меня проставляли PaX-флаги, я бы тоже не грустил. Но почему-то PaX никто не хочет внедрять в стандартную поставку ОС общего назначения. Вероятно, потому что он слишком хорош для них?

Ну и да, разрешения pledge не аналог PaX-флагов, что ты и сам тут констатировал.

> Так это ты здесь стонешь, как тебе всё неудобно и говно. Тогда как отсутствие выбора в озвученных рамках - это сухой факт.

Только если ты не умеешь писать код, только тогда у тебя нет выбора. Но с учётом твоих претензий на "продвинутость" подобное выглядит как-то жалко что ли.

>> попатчили бы уже то, что нужно. Но нет, испускать шум интереснее. Бог в помощь.
> Мне в системах с grsecurity не нужно ничего патчить. PAX_MPROTECT включён по умолчанию, исключения заданы, всё работает. Могу себе позволить повысказываться об особо важных и весомых мнениях, вроде твоего.

Это видимо настолько сильный аргумент, что ты повторяешь его уже не в первый раз. Призывать тебя подумать и порассуждать более не буду, ибо ты не пытаешься. Посмотрим, что будет в будущем.
Да, и я могу быть не прав, я это понимаю.

>>> Сделать патч, пересобрать, развернуть.
>> Отослать патч автору ПО, добиться включения в кодовую базу, забыть навсегда.
> То ли дело строчку в /etc/paxctld.conf прописать... Непосильная задача!

Во-первых - да, привет pax(ctl)d. Почему-то, массы не очень хотят настраивать это руками. Наверное, потому что это очень преочень просто?
Во-вторых, зачем что-то настраивать каждый раз (на каждой новой работе/проекте), если можно настроить _один_ раз вообще?

> Не нужно решать проблему, котрой нет. Это ты будешь носиться с патчами, если захочешь ограничить PROT_EXEC. А у меня в системах с grsecurity ограничения включены по умолчанию.

Конечно же, я не буду с этим носиться. Производственной нужды у меня сейчас нет, а локалхост переживёт. А если очень пригорит - попатчу для себя, это предельно легко. Или PaX возьму - я не гордый и не фанатик. Всё зависит от поставленной задачи.
Да, сейчас grsec может чуть дешевле предоставить гарантии защиты памяти для тех приложений, которым не нужен prot_exec. А в перспективе - телодвижений с pledge будет меньше, а PaX будет настраиваться всё тем же костыльным, наружным способом.

> С чего ты вообще взял, что я чего-то не знаю и нуждаюсь в твоих рассказах? Ты спросил, уточнил? Нет. Сразу побежал простыню строчить, потому что умным хочешь показаться. Это для тебя главнее, чем любые конструктивные обсуждения и факты. За что и огребаешь, если ещё не понял.

Я, для начала, не понял, что "огребаю". Ты очень высокого мнения о себе.
Нуждаешься ты или нет в моих рассказах - мне в принципе всё равно, к общению со мной я тебя не принуждаю, это добровольное дело. Но ты набросил и мне есть что сказать. И основная мысль этого "есть что сказать" такова: мерами "защит ядра" меряются только дети и идиоты. То, что в grsec, например, пытается решаться KASLR, в OpenBSD пытаеются решать KARL'ом. OpenBSD не реализует PaX, PaX не реализует OpenBSD, это разные решения и разные подходы, сравнивать их в лоб - дилетантство.

>> а также не просадить до невозможности производительность.
> FUD. Факты где? Фактов нет.

Факты того, что OpenBSD не стремятся просадить произвоительность? Ну вот тот же KARL сделали так как сделали, чтобы избежать накладных расходов на kernel ASLR.

> И сколько людей пользуются этой ОС общего назначения?

Откуда я знаю? Но если ты думаешь, что grsecurity фантастически популярен, ты выдаёшь желаемое за действительное. Я не думаю, что OpenBSD фантастически популярен.

>> Что касается патчей от PaX, то даже во времена открытого grsecurity не было ни одного "серьёзного" дистрибутива, использующего наработки PaX и чтобы они был включены по умолчанию.
> Что из этого следует? Ты не намекай, ты прямым текстом говори.

PaX - "слишком хорош" для этого. Слишком удобен для бескостыльного и негемморойного внедрения. Не надо чпокаться.

А как нишевое решение может быть и правда годен - если подходит по требованиям.

> Пользователи grsecurity, включая меня, годами используют кастомные ядра с дисрибутивами общего назначения.

Если вы поставили в условный debian ядро, не реализующее стандарт всецело (например, во имя усиления безопасности), уже нельзя говорить, что используется ОС общего назначения. КО.

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

В контексте или без, то что ты предлагаешь - уродливый костыль, который делать ни в коему случае не надо, в OpenBSD такому уродству не место. Хотеось бы отозвать prot_exec везде - это сделали бы как в pax. Суть в том, что так делать не хотели ОСОЗНАННО, и чинить это типчным линуксвеем - НЕ НАДО. Ты думаешь, что нюансы, на которые ты пытаешься обратить внимание имеют какое-то значение, но напротив, они не принципиальны, ты предлагаешь уродливый костыль и удивляешься, что никто не в восторге. Это странно. Особенно в свете того, что ты сам оценил идею с LD_PRELOAD как смешную.

>> Суть pledge - сделать удобный api для privilege revocation, а не слепить костыль для принудительного отключения prot_exec.
> Сколько раз ты ещё намерен это повторить?

В теории - пока не дойдёт до собеседника. На практике, мне скоро станет лень и я сольюсь.

> Ты ведешь себя соответствующим образом. Будто хочешь казаться. Самолюбование при даче непрошенных разъяснений так и прёт. Оценка ценности собственного мнения - так и закшаливает.

Нет смысла пытаться задеть меня.

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

На бесптичье, как говорится, и жопа соловей. Пока нет нормальных инструментов, и selinux сгодится.
И если бы ты читал то, что я тебе пишу, ты бы увидел, что я не отрицаю того, что решения типа селинукса имеют область применения. Только эта область применения не связана с защитой программ от самих себя (от дыр в них), она про сложные политики доступа к данным и ПО в сложных организациях.
Почему-то этой простой мысли ты понять никак не можешь, или не хочешь.

> Ага, и операционку свою напишут. За пару вечеров. Тебе сколько лет, уважаемый? С понятием запретительно высоких издержек знаком?

Смешно. Зачем так люто передёргивать и сравнивать проверки тривиального (не полноценный аудит, да) и написание ОС? Сказать по-существу нечего?

>> А _по_умолчанию_ должен быть максимально безопасный вариант, но в пределах допустимого стандартом, если заявлена поддержка оного.
> Кому должен? Почему должен? Потому что ты так сказал? В OpenBSD могут делать всё, что захотят, в том числе промывать мозги своим доверчевым пользователям. А свои претензии на универсальные критерии можешь употребить по назначению.

Тот, кто заявляет, что выпускает POSIX-совместимую ОС, тот и должен. Потому что иначе это ЛОЖЬ. А тот, кто её испускает - ЛЖЕЦ.

> Ты везде продолбался и продолжаешь. Но поймёшь это нескоро, похоже, если вообще поймёшь.

Продолжай убеждать себя в этом. Ты так много нападаешь на мою "экспертизу" и на мою личность вообще, но так мало пишешь по делу.. Один раз ты подловил меня с pledge, но почти всё остальное - переливание из пустого в порожнее и неспособность признать очевидное. Поэтому и "надрачивание".

>> В целом согласен
> А это не важно, согласен или нет. Цель анализа в другом. Носом тыкать не стану, всё ты понимаешь прекрасно.

Честно - не вполне. То ли ты не понимаешь, то ли троллишь. Есть и более грустные варианты, но опускаться до них я не буду.

>> хотя и большой проблемы в более позднем отзыве prot_exec не вижу - инициализация  обычно это в худшем случае секунды, это не успеют использовать. Но да, prot_exec отзовётся уже при первом вызове pledge, который нужно делать как можно раньше.
> Потому не видишь, что у тебя в голове вместо относительно глубокого и широкого понимания, условно достаточного для обоснованного вынесения суждений по этим вопросам - какой-то отдельный юз-кейс. Типа того же браузера.

Браузер - это только пример нужного приложения, которое требует нарушения W^X и для которого использование pledge и unvel может быть практичнее, чем PaX.
Что касается эксплуатации возможности переключения памяти в +x до того как это будет сделано pledge после инициализации, то я могу допустить, что такое в принципе возможно (можно хоть относительно недавний local root в xorg вспомнить, где дыра чуть ли не в разборе аргументов командной строки была, ну т.е. на стадии инициализации), но шансы на эксплуатацию подобного в реальном мире невелики. Обрати внимание, prot_exec по умолчанию не отзываю не лично я, а очень многие люди, не только разработчики OpenBSD. В роли д'артаньяна выступаешь сейчас ты, на белом коне. Жаль только, с высокомерным умничанием, вместо чего-то по существу.

> Всё будет работать. Просто ты подумать не потрудился: а вдруг собеседник не глупее тебя и имел ввиду не включение-отключение, а поэтапную безвозвратную установку ограничений, но в заданных местах. Например, на этапе инициализации запретить использование PROT_EXEC, а после listen() - доступ к файлам.

Просто если собеседник имел ввиду это, то не понятно, зачем он предлагал выносить это во внешний конфиг и настраивать ограничения для каждой процедуры отдельно. У такого подхода могут быть преимущества только в том случае, если можно зарезать каждую процедуру до МИНИМАЛЬНО ей нужного. А так как это нельзя, нет смысла городить описанное собеседником, достаточно N раз сбросить привилегии и всё. Как это и предлагается в pledge.

>>> Использовать LD_PRELOAD - тоже. Хотя бы потому что LD_PRELOAD игнорируется для suid
>> и sgid бинарников, лепить ещё один костыль для обхода этого - странно.
> Только переменная среды игнорируется, а содержимое /etc/ld.so.preload - нет. Костыль лепить не нужно. А вот знать, о чём говоришь, или молчать, о чём знаешь мало - не повредило бы.

Мы про какую ОС? В linux нет pledge, в openbsd нет ld.so.preload.

> Равный результат существует только у тебя в голове. Как и все якобы существенные трудности в случае с PaX. На практике нет никакого равного результата. С PaX я задаю ограничения для всей ситсемы, сразу, и затем либо ослабляю их для отдельных приложений, либо эти приложения не работают и поверхность атаки не открывают

Пока только в голове, да. Ну и для небольшого числа приложений. Это так и задумано. Я в кнопки "сделать безопасно", прости, не верю. И PaX mprotect оной не является.

> В любом дистрибутиве.

Ну что ты врёшь, а? Это ж элементарно всё проверяется. Из коробки этого нет нигде. И не было.
А после того, как код grsec закрыли, и те hardened-вариации дистрибутивов, что были - загнулись.
И вкорячив grsec-ядро, вот просто так, в обычный дистрибутив, ты получишь нерабочую систему. Оттуда все костыли типа paxd и выросли.

> Не может pledge дать сравнимый по качеству результат. Просто потому что в случае PaX ограничения легко снимаются по белому списку, а в случае pledge - выставляются по чёрному списку.

Естественно, pledge ещё "не дорос" до того, чтобы ломать приложения ради "безопасности". В реальном мире, а не в фантазиях секурити-гиков, вахтёрство и прочее "не пущщать" работает не очень. А 3.5 пользователей hardened gentoo, при всём уважении, никому особенно не интересны. Да и нет их больше, как и опенсорсного grsec.

> С совершенно несопоставимыми трудозатратами. Это факты.

Конечно. Ведь в случае pledge работу нужно выполнить 1-2 раза и разработчику/мэйнтейнеру. А потом больше никогда. Куда лучше накладывать PaX-патчи (где бы теперь взять их ещё?), собирать своё ядро, расставлять pax-флаги и поддерживать всё это в актуальном состоянии. Это факты.

> ставишь ли ты выше требований безопасности априорную поддержку устаревших стандартов или нет - сугубо твоё личное дело.

Не знаю, кто дал тебе право называть общеиспользуемые стандарты устаревшими, но пока есть нужные приложения, которые их используют соблюдать их надо. Нарушать стандарты можно и просто так, но тогда нужно не врать, про то, что всё будет работать, а кричать на каждом углу, что будет сломано то-то и то-то, чинить такими-то костылями. А не рассказывать про "гарантии безопасности", которых нет, как и совместимости с posix.
Но да, если проект не ставит цель поддерживать стандарты, глупо ему за это предъявлять.

> Не там, а практически везде. ...... Это даже не смешно. Это убого.

Честно - мне без разницы. Ты думаешь, что убого не знать, что paxctld по умолчанию, а не paxd, а я думаю, что само наличие такого демона - это убого.
Твои предположения о моём опыте использования grsecurity и моих знаниях о нём не тоже не интересны. Мне приходилось связываться с grsecurity, и так вышло, что с paxd, и речь не только об втором десктопе на арче, на котором у меня N лет было grsec ядро, пока можно было.
Так что право на мнение я имею. А твои постоянные попытки уличить меня во всяком куда больше говорят о тебе, чем обо мне.
Если тебе интересно, никаких проблем у меня с grsec в проде не было. Мне казалось, что мы сравниваем подходы, а ты мне продолжаешь рассказывать про неимоверную сложность pledge-патчей и неимоверную простоту и идеологическую верность pax-флагов. Это не смешно, и даже не убого, это просто феерически тупо.

>> Это именно что сорта говна.
> Воспитание твоё - сорт говна.

Это не новость. Найди, пожалуйста, технический аргумент, типа как про pledge в тот раз, или просто конструктив, как про paxctld. Воззвания к моей совести бессмысленны.

> Не отвертишься теперь.

Даже пытаться не буду. Мне признавать свою неправоту легко и приятно. Ну вот у меня был опыт связанный с paxd, так уж сложилось, и да, мне никогда сильно не было интересно, какие костыли идеологически верно лепить вместо него. Отвратителен сам подход.

> Всё происходило в Hardened Gentoo, где флаги выставляются пакетным менеджером, представь себе.

Ок, буду знать. Вау, кто-то сделал нормально, а не через Ж. Жаль, что hardened gentoo, ЕМНИП, не вполне самостоятельный дистрибутив.
Ну и жаль, что лично меня от gentoo тошнит, но к спору это уж точно отношения не имеет.

> Ага, надо, потому что ты, анонимный не-эксперт, сказал. Который не читал, но осуждает. И да будет тебе известно, рассуждальщик, что аналог "пакетов с xattrs" - это прошлое PaX. Когда-то флаги выставлялись через ELF-заголовки

А я знаю про это, про ELF-заголовки. Зачем ты опять гадаешь?

> Естественно, файлы с заголовками, модифицированными на поздней стадии сборки пакетов (или на ранней стадии установки пакетов, если делать это в дебианах через хуки dpkg), сохраняли значения флагов, будучи запакованы в архив любого формата. Но сообщество пользователей grsecurity, включая дистростроителей, в своё время отдало предпочтение флагам в xattrs и демону paxctld. Причём, не сговариваясь. Потому что это удобнее.

Нет, потому что править ELF-заголовок не при сборке пакета (как, видимо кроме Hardened Gentoo никто не делал) = заставлять пакетный менеджер ругаться на битые чексуммы у пакета. А так как никто не поспешил добавлять божественный pax в базовую поставку мейнстримных дистрибутивов пришлось лепить костыль с xattrs. Который можно не пихать в пакеты, где он дистроклепатеям нафиг не нужен, а запустить моднейший демон paxctld.
Маневрирование 80 уровня.

>> кажется, вполне могу обосновать правильность своей позиции.
> Нельзя обосновать правильность свей позиции в категориях а ля "неудобно", "ненадёжно", "неправильно" и т.п. без технической конкретики.

Я объяснял и почему неудобно, и почему не надёжно, не надо тут. И про то, что MAC применяется до запуска бинарника, а не во время, поэтому требует кучу доступных для чтения путей, и про необходимость настройки там, где её не должно быть, и про уродливые демоны для pax-флагов, и про возможность сбрасывать привилегии по разному в разных процессах программы.
Но зачем это читать, это же вода? Гораздо лучше придолбаться к обощающим характеристикам и делать вид, что я ничего более не писал.

>> Заморачиваться лень, простой контрпример - KARL.
> Не лень, а ничего ты толком не знаешь и ляпнуть лишнего боишься.

Да как скажешь.

> Сравниваешь зрелый быстрый CFI и плагины для автоматического устранения уязвимого к Specter кода - с KARL! Ты ещё про securelevel вспомни.

Я не сравниваю, а привожу контрпример. Не надо врать потому что. Ни тогда, ни сейчас.
А вот ты сравниваешь полноценную ОС и патчи (закрытые) к ядру Linux, в котором и без них куча всего интересного. Типа как dirty cow, когда никакой grsec ничем никому не помог, но это к слову.
И сравниваешь ты на уровне "кукурити-фич", т.е. в лоб, т.е. без учёта импакта и сложностей при внедрении и подобного. Это детский сад.
Я вполне допускаю, чтобы ты не думал, что grsec могут сделать что-то, решающее ту или иную проблему. Но пока это сторонние патчи (даже если и опенсорсные, как раньше) - это всё игрули для секуьюрити-энтузиастов и proof of concept. Я могу поверить, что те или иные проблемы решены, но не могу поверить в то, что это "бесплатно". А это имеет значение.

> Если бы ты прочитал и попытался усвоить прочитанное, то понял, что я не делал утверждений об отсутствии механизмов защиты ядра в OpenBSD, а высказался, что по уровню они не дотягивают даже до PaX начала нулевых.

Вот твоя цитата: "В OpenBSD же на ядерном поприще если и делается что, так только под лозунгами наведения корректности. Явный курс на безопасность они оставили ещё в начале нулевых и с тех пор даже не пытались на него вернуться.".
Ты утверждал, что с нулевых ничего не делается для безопасности ядра, я опроверг. Тупо тем, что вспомнил сразу.
Сравнивать openbsd с pax нулевых мне как раз малоинтересно, писями меряться - это детский сад. Какие-то отдельные решения можно сравнить, если очень хочется, но лично я бы потихоньку закругялся с флудом тут.

> Ты хоть сам понимаешь, что такое "митигации"? И чем они на практике от "наведения корректности" отличаются?

Я? Да ты што, откуда мне, ты ж один тут умный.

> К тому же, из достижимой на практике корректности напрямую не следует никаких свойств безопасности.

Всецело согласен, я даже выступал с подобной позицией против NetBSDшника в какой-то недавней теме тут, который "надрачивал" на "наведение корректности". Тем не менее, я останусь при том, что озвучил ранее: я рад, что openbsd крайне осторожны с внедрением средств смягчения последствий эксплуатации уязвимостей. Любой новый написанный код, в т.ч. "митигация" требует поддержки и может содержать дыры, внедрение и/или эксплуатация может быть "небесплатной" - и прочие остальные банальности.

> А если чуть серьёзнее, то хватаешься за любую возможность показаться умным.

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

> Не было опубликовано. Это больше говорит об интересе, а вернее, отсутствии такового со стороны исследователей безопасности.

Может и так. Но вот тут недавно очень умные, без всяких шуток и иронии, ребята нашли N дыр в компонентах OpenBSD, в том числе и довольно серьёзные. Так что я не стал бы утверждать о полном отсутствии интереса.

>> В целом, за grsec я перестал следить после того, как они закрыли код.
> А раньше следил по публикациям в интернете? ;)

Нет, в журнале "мурзилка". Дело в том, что в нашей школе статьи про grsec обычно публиковалися там.
Петросян.жпг

> Так это pledge опциональный. ...... пытаешься выставить недостатком.

Твои хаки, которые на самом деле костыли, можно заменить тривиальным использованием execpromises, про то, зачем нужен оный в мане всё написано. Т.е. написать pledge-враппер (на самом деле, тоже костыль) не очень сложно.
Но таких целей, насколько я знаю нет, потому что придётся выдавать приложениям куда больше прав, чем им по-факту в main loop нужно -> _потенциально_менее_безопасно_.
Pledge опциональный, да. В том плане, что нельзя принудить к его использованию. Но если он уже внедрён, то его нельзя отключить, разве что такая логика предусмотрена в самом приложении. И в этом смысле он безальтернативен, нет никакой sysctl, которая выключит pledge глобально, нет никакого аналога setenforce=0.

>>> Сперва на "ты" перешёл в фамильярной форме
>> Это не была попытка задеть, мы в интернете, тут общение на ты
> Я к тебе на вы обратился.
>> задело.
> Мечтай. Руки развязало.

Ну т.е. ты искал повод, чтобы начать кидаться говном, нашёл его, и с чистой совестью приступил - я всё верно понял? Поздравляю с успешно найденым оправданием для своего поведения! Лицемерненько так, ничо, мне нравится.

>> Ты принимаешь это слишком близко к сердцу
> Я принимаю это так, как считаю нужным и удобным лично мне.

Мне всё равно. Я желаю тебе этого не для себя, а для тебя - сон спокойнее будет.

> Огребаешь ты не за тыкания и физиологизмы, а за поведение в целом, каковое характерно для обширной группы лиц. Считай, что по случаю отдуваешься "за всех".

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

>> называть [...] не говном отказываюсь.
> А я тебя и не прошу. У меня другие методы.

У тебя самомнение, а не "методы". Ничем, к сожалению, не подкреплённое.

>> Сложно удержаться от соблазна потроллить, когда человек просто не хочет открывать для себя новое, потому что уже есть привычные решения.
> Вот за этим ты сюда и возвращаешься: .... И это тоже заденет.

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

> Да грош цена твоему спасибо. Ты же ведёшь себя как малолетний невоспитанный хам, говнами всё вокруг клеймишь. Кого ты обмануть-то хочешь, меня или себя? Или крестик сними, или штаны надень.

Боже, да какой же ты обидчивый! Слушай, правда, если я так тебя обидел чем-то - извини. Но умоляю, или пиши по существу вопроса, или не пиши, мне ну совсем не интересны твои моралфажеские замечания. Ты тратишь своё время зря. Хам, не хам - это не твоё дело, тебе не жить со мной и детей не растить. Хочешь говорить про pax и openbsd - давай, нет - заканчиваем.

>> И да, экспертом я себя не считаю.
> А кем ты себя считаешь?

А ты-то кто ты такой, чтобы с меня спрашивать?
Я никем себя не считаю, это бесполезное занятие. Но я имею некий опыт и видел некоторое говно. Мало знаю про то, как делать надо, но довольно много про то, как делать не надо. Как-то так.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру