В приложении userhelper и библиотеке libuser, поставляемым по умолчанию в дистрибутивах, основанных на пакетной базе Red Hat, выявлена (http://www.openwall.com/lists/oss-security/2015/07/23/16) серия уязвимостей (https://securityblog.redhat.com/2015/07/23/libuser-vulnerabi.../) (CVE-2015-3245, CVE-2015-3246), позволяющих выполнить код с привилегиями пользователя root. Для демонстрации проблемы приводится рабочий эксплоит, применяемый к приложениям, использующим libuser для манипуляций с учётными записями пользователей.Первая уязвимость присутствует в программе userhelper. Программа предназначена для смены информации о пользователе и примечательна тем, что поставляется с установленным флагом setuid-root. Уязвимость вызвана тем, что при разборе передаваемых опций не осуществляется проверка на наличие символа перевода строки ('\\n'), что позволяет атакующим передать данные, добавление которых в файл /etc/passwd приведёт к появлению новой строки. Так как указание символа ":" запрещено, имеется возможность добавить только неотформатированные строковые данные, что может быть использовано для осуществления DoS-атаки.
Вторая уязвимость присутствует в библиотеке libuser и вызвана особенностью работы с файлом /etc/passwd. В отличие от классических утилит passwd, chfn и chsh которые вначале создают временный файл с копией /etc/passwd, модифицируют его и заменяют основной файл, в libuser применяется прямая модификация /etc/passwd. Если в ходе манипуляций с /etc/passwd произойдёт ошибка, файл может остаться в некорректном виде. Путём определённых манипуляций, в сочетании с первой уязвимостью, можно добиться очистки записи для пользователя root ("\\na::0:0::/:\\n") или осуществить подмену поля с shell и домашней директорией, что даёт возможность организовать выполнение кода с правами root.
Дополнительно можно упомянуть выявление уязвимости (http://www.openwall.com/lists/oss-security/2015/07/22/7) (CVE-2015-3290) в коде работы с NMI в ядре Linux, позволяющей инициировать крах ядра или выполнить код с правами root. Сообщается, что для уязвимости уже имеется готовый эксплоит, который будет опубликован только через одну-две недели, чтобы дать пользователям время обновить свои системы. Проблема проявляется на системах с архитектурой x86_64 при использовании ядра Linux 3.13 и более новых версий.
URL: http://www.openwall.com/lists/oss-security/2015/07/23/16
Новость: http://www.opennet.ru/opennews/art.shtml?num=42657
# apt-get remove usermode и дело с концом
>>в дистрибутивах, основанных на пакетной базе Red Hat$ sudo rpm -e usermode
</зануда>
>>в дистрибутивах, основанных на пакетной базе Red Hatвы не поверите, но этот непонятный треш также штатно присутствует и в Debian. и никто его явным образом в трезвом уме и ясной памяти не ставил.
А у меня apt написал что usermode у меня нету :)
>>треш также штатно присутствует и в Debian$ sudo aptitude purge usermode
Ни одного пакета не будет установлено, обновлено или удалено.$ aptitude search usermode
p usermode Graphical tools for certain user account management tasksА у меня такого нет =)
> А у меня такого нет =)На 7ке у меня его тоже нет. А вот в 8.1 после апа с 7ки есть (был).
> В отличие от классических утилит passwd, chfn и chsh которые вначале создают
> временный файл с копией /etc/passwd, модифицируют его и заменяют основной
> файл, в libuser применяется прямая модификация /etc/passwdЭто ж насколько нужно быть криворуким, чтобы так писать код? На помойку либу.
>>> даже в windows и то быстрее.Поржал.
Они недавно пофиксили баг безопасности который живет еще с NT.ЗЫ
И докажи что это не так.
> Это ж насколько нужно быть криворуким, чтобы так писать код?Это современная/корпоративная модель OpenSource. Один человек пишет [произвольно кривую] софтину, миллионы "пользователей" тестируют и методом случайного тыка находят видимые ошибки (которые практически сразу, максимум в течение года, исправляются), после чего софтина объявляется морально устаревшей и ей на смену приходит новая версия, несовместимая и неотлаженная, при этом весь софт переписывается на работу с новой версией и всё повторяется.
И все счастливы: "пользователи" получают бесплатный софт, производители - бесплатных тестировщиков.
А если этот "бесплатный", как вы написали, софт пишет не компания а один-два человека? А особенно, когда софт нужный. Примеров в OpenSource достаточно. Так что ваша теория не всегда работает.
>> Проблема проявляется на системах
>и так и не могли высмотреть и исправить ошибку..Как?! Не смогли?? Безобразие! Дезинформация там неверху? И в скачанных мною с утра патчах к дебиановским ядрам? Во всех 9ти штуках. С хвостиком. <\\\><
Торвальдс говорил что его закон про тысячи глаз уже не работает.
> Торвальдс говорил что его закон про тысячи глаз уже не работает.Один процент это тысячи глаз)))
пруф?
Не могу найти цитату. Но разве Heartbleed или еще другие "застарелые" критические дыры тому не доказательство?
> Не могу найти цитату. Но разве Heartbleed или еще другие "застарелые" критические
> дыры тому не доказательство?Тому, что Торвальдс что-то там "говорил"? Санитары1!1
> сколько летLinux 3.13. Меньше года.
Ну давай расскажи нам, как бы ты написал данный код. А я тебе потом распишу в чем криворукость твоего решения.
начнём с того, что без специальной квалификации и глубого знания linux я не стал бы писать setuid код. setuid - это флаг того, что у тебя в руках бомба замедленного действия. Обезвреживать её должен профессиональный сапёр.
> начнём с того, что без специальной квалификации и глубого знания linux я
> не стал бы писать setuid код. setuid - это флаг того,
> что у тебя в руках бомба замедленного действия. Обезвреживать её должен
> профессиональный сапёр.поэтому нужно из всех линуксов удалить ping, да ?
Проблема в том, что программисды не делают проверку входных данных должным образом.
ping и traceroute прекрасно работают без suid с помощью capabilities
что бы их поставить - нужно быть рутом.. да и напомните когда с них сняли suid bit?.. год назад? или меньше?
В ядре давно есть ping-сокеты.
Не нужно, в линуксах давным давно setcap используется.
Профессионалы написали винду, любители создали линукс.
Но в данном случае речь шла о коде, который изменит данные в файле, suid здесь вообще не причем. Да и вопрос был задан не всем, а только кричащему о криворукости, мне хочется увидеть его решение.
> Профессионалы написали винду, любители создали линукс.ты что курил? это IBM это любители? это HP любители? это RedHat любители? не.. подкинь адрес своего драг-диллера? хочу купить такую же траву.
кури вот это.
http://www.opennet.ru/opennews/art.shtml?num=37926
чем дальше - тем меньше вклад любителей.А теперь выдыхай бобер, а то передоз будет.
> Но в данном случае речь шла о коде, который изменит данные в
> файле, suid здесь вообще не причем. Да и вопрос был задан
> не всем, а только кричащему о криворукости, мне хочется увидеть его
> решение.open(O_TMPFILE) или open + unlink для временного файла.
или использование berkleyDB как в BSD системах, для большого количества юзеров сильно быстрее чем сканирование текстового файла.
> ты что курил? это IBM это любители? это HP любители? это RedHat
> любители? не.. подкинь адрес своего драг-диллера? хочу купить такую же траву.Если русский не родной, то настоятельно рекомендую поинтересоваться у окружающих, что значит "создали" и чем оно отличается от "развивают в данный момент".
> open(O_TMPFILE) или open + unlink для временного файла.Если ты не понял, то я повторю задачу: "правильно отредактировать имеющийся текстовый файл общего пользования". Твой вариант пока даже не отредактировал, не говоря уже о правильности. Понятие "алгоритм" тебе вообще известно или знания программирования ограничиваются словом "криворукие"?
> или использование berkleyDB как в BSD системах, для большого количества юзеров сильно
> быстрее чем сканирование текстового файла.Зачем скромничать, сразу оракл юзай.
поинтересуйся кто создал из школьной поделки нормальный продукт.. ну так для истории.> Если ты не понял, то я повторю задачу: "правильно отредактировать имеющийся текстовый файл общего пользования". Твой вариант пока даже не отредактировал, не говоря уже о правильности. Понятие "алгоритм" тебе вообще известно или знания программирования ограничиваются словом "криворукие"?
Твои знания уже видны. open(O_TMPFILE) + rename на место старого - решает очень много проблем с атомарность доступа. так же как и open+unlink + rename. Но видимо тебе надо все разжевывать, без этого ты ну никак не поймешь.
> Зачем скромничать, сразу оракл юзай.спасибо поржал с твоих знаний ;-) пейсши есшо..
сколько школьников набежало.. каникулы вот и маются..
Ну тут могу сказать только стандартное: "слив засчитан". Возвращайся, когда осилишь понятие алгоритма и тебе вдолбят, что такое решение задачи. А пока тебе до "криворуких" расти и расти.
может тебе еще UML диаграммы нарисовать? хотя.. что школоту спрашивать они таких слов не знают.. только твердят "слив засчитан" на все что не в состоянии охватить своим умишком.
Деточка, я программированием занимался, когда UML еще не придумали. Можешь и UML диаграмму нарисовать, если тебе будет легче. Ты хоть что-то сделай кроме демагогии и кидании обвинений в криворукости. Я бы мог и за тебя набросать твой примитивный алгоритм, но ведь, когда начну показывать его проблемы, ты начнешь вилять задницей. Так что будь добр, распиши или нарисуй его самостоятельно.Давай я тебе покажу пример того, что я от тебя хочу увидеть. Предполагаемый "криворукий" алгоритм может выглядеть так
1. Открыть исходный файл на чтение
2. Объявить shared блокировку
3. Прочитать содержимое
4. Закрыть исходный файл и снять блокировку
5. Изменить содержимое в памяти
6. Открыть исходный файл на запись
7. Объявить exclusive блокировку
8. Записать новое содержимое
9. Снять блокировку.
10. Закрыть исходный файл
Осилишь подобное или тебе нужно UML диаграмму нарисовать?
> Осилишь подобное или тебе нужно UML диаграмму нарисовать?Тебе уже предложили вариант с атомарными изменениями, но ты его почему то игнорируешь. И он гораздо проще твоего школьного представления о безопасности, лол.
Пока ничего не предложили. Если ты вдруг не понял, то я привел пример как может выглядеть имеющийся проблемный алгоритм в libuser. Хочу увидеть настолько же подробный вариант решения от кидающегося обвинениями в криворукости.
Информация к размышлению, хоть rename и можно считать атомарной операцией, но вот только это лишь часть действий по редактированию файла. И даже если все остальные операции тоже атомарные, то их совокупность атомарной операцией чаще всего не является. Доступно объясняю?
LOL :)ты знаешь что такое open+unlink или O_TMPFILE и зачем они придуманы? видимо нет. Перестань кичится и открой учебники, после чего выкинь свой алгоритм на помойку. shared блокировки ему потребовались.
Умник ;-)лана - общаться с человеком который не имеет представления о предмете уже скучно.
> ты знаешь что такое open+unlink или O_TMPFILE и зачем они придуманы? видимо нет.Прекрасно знаю и давно использую. А вот ты понятие алгоритма так и не осилил.
>после чего выкинь свой алгоритм на помойку. shared блокировки ему потребовались.
> Умник ;-)Для тупых повторю еще раз. Это НЕ мой алгоритм для редактирования файлов, это НЕ рекомендуемый вариант. Это был пример для тебя как может выглядеть решение задачи редактирования файла. Еще раз(хотя скорее всего все равно не дойдет), это НЕ верное решение задачи, просто ПРИМЕР.
> лана - общаться с человеком который не имеет представления о предмете уже скучно.
С учетом того, что ты за эти дни так и не смог написать хоть какой-то алгоритм, то мне уже ясно, что мои изначальные предположения о твоем уровне в программировании и неправомерности обвинений в криворукости с твоей стороны оправдались. Больше мне от тебя ничего не надо, время, данное тебе на решение задачи, истекло.
> Возвращайся, когда осилишь понятие алгоритма и тебе вдолбят, что такое решение задачи.Так он и привёл ключевые точки.
> А пока тебе до "криворуких" расти и расти.
Из изложенного Вашим оппонентом очевидно, что нет (я было набросал менее подробный ответ, потом полистал ниже и выкинул свой за ненадобностью).
> Так он и привёл ключевые точки.Он всего лишь повторил за автором оригинальной новости про вариант с созданием временного файла и его последующим переименованием. А вот написать полный алгоритм надежного редактирования файла так и не осилил, предпочтя уйти в демагогию. В этом же вопросе важна не основная идея, а именно детали.
>> Так он и привёл ключевые точки.
> Он всего лишь повторил за автором оригинальной новости про вариант с созданием
> временного файла и его последующим переименованием. А вот написать полный алгоритм
> надежного редактирования файла так и не осилил, предпочтя уйти в демагогию.
> В этом же вопросе важна не основная идея, а именно детали.учи матчасть. Даже до шигорина дошло, а вот до тебя нет. Детали тебе указали, но твой уровень тебе не позволяет их увидеть.
>> или использование berkleyDB как в BSD системах, для большого количества юзеров сильно
>> быстрее чем сканирование текстового файла.
>Зачем скромничать, сразу оракл юзай.О! ангра выздоровел, оно снова порет чушь! :)
Это ты бувы DB увидел и по рефлексу запел об оракляХ :)Так вот - есть такая штука SQLite - замечательная и легковесная. Аффтор говорит думайте про эту либу как про замену fopen() :) Она размером с awk и понимает не хилый кусок SQL-я.
Так вот - BerkelyDB - это key-value, очень маленькая и очень быстрая.
Фсё!
Лекцию окончил, тем кто надо - погуглил, подумал да и понял.
ангра - не понял и не поймёт! :)
Oracle как еще более "глобальный и надежный" вариант, чем BDB или sqlite, приведен был для иллюстрации глупости подхода, когда вместо решения исходной задачи - редактирования текстового файла - начинают прелагать заменить его на более подходящий для изменений формат. Похоже для некоторых ирония оказалось слишком тонкой.
>>> или использование berkleyDB как в BSD системах
>>Зачем скромничать, сразу оракл юзай.
> О! ангра выздоровел, оно снова порет чушь! :)
> Это ты бувы DB увидел и по рефлексу запел об оракляХ :)Вам привет от википедии, проприертарщику - проприертарщиково.
"Berkeley DB" is also used as the common brand name for three distinct products: Oracle Berkeley DB, Berkeley DB Java Edition, and Berkeley DB XML. These three products all share a common ancestry and are currently under active development at Oracle Corporation.
> Так вот - BerkelyDB - это key-value, очень маленькая и очень быстрая.
> Фсё!
>>>> или использование berkleyDB как в BSD системах
>>>Зачем скромничать, сразу оракл юзай.
>> О! ангра выздоровел, оно снова порет чушь! :)
>> Это ты бувы DB увидел и по рефлексу запел об оракляХ :)
> Вам привет от википедии, проприертарщику - проприертарщиково.
> "Berkeley DB" is also used as the common brand name for three
> distinct products: Oracle Berkeley DB, Berkeley DB Java Edition, and Berkeley
> DB XML. These three products all share a common ancestry and
> are currently under active development at Oracle Corporation.что такое главное имя а что такое "also used" - видимо митрофанову сложно усвоить.
а уж что бы узнать - какой же из вариантов используется в bsd системах... да ты че - это же святотатство и отступлении от религии!
> Профессионалы написали винду, любители создали линукс.кстати - стоило бы сравнить Linux как всю экосистему - включая DE и Windows.
Да да, включить в общее количество багов еще KDE, GNOME, ... и почтовых клиентов..сдается мне что багов будет сильно больше, если почитать соотвествующие бюллетени.
Так что кончай передергивать и вставай на лыжи.
Да-да, заодно придется раскрыть код проприетарщины. Давайте-давайте. А с какого сравнивать все окружения с одним единственным виндовым? Крыша едет не спеша тихо шифером шурша?
в состав windows входит почтовый клиент, DE и все такое. CryptoAPI этакий OpenSSL..
все это - таки Windows.Так чего же вы количество багов сравниваете только с ядром Linux?
> в состав windows входит почтовый клиент,Да ну?!?! И как же он называется?
outlook express уже выпилили ? а ведь идет в базовой установке :)
Товарищ, вы только что вышли из анабиоза. На дворе 2015 год. Аутглюк экспресс отсутствует в базовой поставке как минимум с виндовс7. Про свисту не скажу, не приходилось в говно со скафандром нырять.
Я правильно понимаю, что ты предлагаешь сравнить весь софт под линукс, со всем софтом под винду? Это конечно можно, но как это относится к качеству самих ОС?Количество исправленных багов не так важно, как количество известных существующих и остающихся годами.
> Я правильно понимаю, что ты предлагаешь сравнить весь софт под линукс, со
> всем софтом под винду? Это конечно можно, но как это относится
> к качеству самих ОС?предлагаю сравнивать не весь софт - а тот кто обеспечивает одинаковую функциональность.
если в Windows включен GUI, то и со стороны Linux надо добавить к списку сравнения - DE.
если в windows существует cryptoapi - то и в linux надо добавить openssl,
если в windows включен shell, то в и linux добавить bash,и тп..
а потом сравним сумарно количество багов в обоих списках.
боюсь только линуксоидам сравнение не понравится.
> предлагаюОдноклассникам своим предлагай, ламерок малолетний.
Ну давай попробуем.
В линуксе есть ssh, что предлагает windows? Будем сравнивать ssh против rdp?
В линуксе есть perl, что предлагает windows? Неужто с VB сравнивать.
В линуксе есть четыре DE и куча WM, что предлагает windows? Их даже между собой нелегко сравнить, разные задачи, разные приоритеты при разработке, как следствие разный функционал и степень стабильности.
Дальше продолжать или идея ясна?Но все-таки кое-что сравнить можно. Например живущие годами и десятилетиями эпичные баги/фичи в системном софте. Например то, что винда всегда переписывает MBR, более того, способна поставить первичный загрузчик на один винт, а вторичный на другой, что при разнесении винтов приводит к невозможности загрузить систему. Считаю это эпичным. А как насчет утилит, которые на вход принимают параметры в одной кодировке, а вывод выдают в другой. Само собой в их help об этом ни слова. Или вот из недавнего, chkdsk в win 7. Ну ладно арифметику для дебилоидов, когда 0.5% и 20% он считает за 10% можно простить, но вот то, что он сожрал все доступные ему 14гигов оперативки, после чего просто завис без возможности его убить, считаю просто образцом криворукости. В линуксе из долгожителей могу вспомнить невозможность пользоваться глобальными шорткатами при открытом меню в иксах и буфер обмена, привязанный к программе, из которой было осуществлено копирование. Тоже неприятно, но уровень несколько иной.
> Ну давай попробуем.
> В линуксе есть ssh, что предлагает windows? Будем сравнивать ssh против rdp?ssh :-)
> В линуксе есть perl, что предлагает windows? Неужто с VB сравнивать.
perl ;)
> В линуксе есть четыре DE и куча WM, что предлагает windows? Их
> даже между собой нелегко сравнить, разные задачи, разные приоритеты при разработке,
> как следствие разный функционал и степень стабильности.
> Дальше продолжать или идея ясна?ну попробуй :)
> Но все-таки кое-что сравнить можно. Например живущие годами и десятилетиями эпичные баги/фичи
> в системном софте.Недавний баг в ядре Linux не исправленый с времен 2.6 бородатых, стопку багов в samba (ведь у windows тоже есть свой SMB2).. будем дальше продолжать или идея ясна ?:)
> ssh :-)
> perl ;)Они уже есть в дефолтной поставке windows? Либо в win10 что-то поменялось, либо ты слишком тупой, чтобы проследить дискуссию.
>Недавний баг в ядре Linux не исправленый с времен 2.6 бородатых, стопку багов в samba
Конкретику пожалуйста. Телепаты в отпуске.
> предлагаю сравнивать не весь софт - а тот кто обеспечивает одинаковую функциональность.
> если в Windows включен GUI, то и со стороны Linux надо добавитьОкай ... ели линукс крутится на 99% топ-500 то расскажите как там у форточки :)
> и тп..
> а потом сравним сумарно количество багов в обоих списках.
> боюсь только линуксоидам сравнение не понравится.Я не боюсь. Я в отличие от тебя в гетерогенке живу. Винда сольёт с гомерическим грохотом. Я сказал! АзЪ. (Особенно если в сети есть Exchange 2007-10-13 и SharepoinдЪ - это ппц)
> предлагаю сравнивать не весь софт - а тот кто обеспечивает одинаковую функциональность.Вы, боюсь, окажетесь неспособны даже выкатить критерии одинаковости.
>> предлагаю сравнивать не весь софт - а тот кто обеспечивает одинаковую функциональность.
> Вы, боюсь, окажетесь неспособны даже выкатить критерии одинаковости.странно только когда находят багу в jpeg встроеном в винду - это считается баг в винде,
когда тоже самое в libjpeg - "ну это же не баг в линукса"..
>>Это и есть NIH-синдром в самом красочном представлении.Только в Красношапке, заметь.
>>Написали их только для того, чтобы написать.
Как будто что-то плохое. Учиться важно и хорошо.
Mir и Unity тоже Красношапка велосипедит?
Значит линуксятники можно говорить, а виндуз****** нет. Понятно с вами все opennet $-)
> Значит линуксятники можно говорить, а виндуз****** нет. Понятно с вами все opennetУ Вас, видимо, акцент неправильный -- вот смотрите: виндоузятники. :)
> $-)
Вот примерно за это я и не люблю конкретный кусок юниксвея - текстовые и подобные форматы обмена данными внятной типизации и требующие экранирование. а также - текстовые форматы, требующие экранирование и не умеющие произвольный доступ к файлу. А заодно - 1000 форматов конфигов и 10000 парсеров/писалок для них.Хотя, казалось бы - чего не гонять данные в каком-нибудь protobufs? Чего не использовать в работе компилированный в бинарь конфиг, с эффективным доступом и с проверенным при компиляции синтаксисом?
> Вот примерно за это я и не люблю конкретный кусок юниксвея -
> текстовые и подобные форматы обмена данными внятной типизации и требующие экранирование.Нужно больше публичных платформ для улучшения кодовой базы юзерленд софта.
Coverity делает пользу для Open Source.
Это к чему было?
> Это к чему было?Все дистрибутивы линукса друг–друга ненавидят, работают против линукса и создают прецеденты для ненависти.
>> Это к чему было?
> Все дистрибутивы линукса друг–друга ненавидят, работают против линукса и создают
> прецеденты для ненависти.Зато маководы любят друг друга. Регулярно. И держась за руки ходят на iПарады.
Не понял, а почему твой пост сделан в этом гадком текстовом формате без внятной типизации, а не "скомпилирован в бинарь"?
Потому что цель поста - писание/чтение людьми. А вот цель /etc/passwd, кк и кучи других конфигов - в первую очередь чтение машиной. С другой стороны, как только в HTML оказывается что-то большое, вроде книги - его иногда и компилируют в бинарь - от EPUB до PDF.Опять же, компиляция в бинарь сто лет как успешно применяется в том же постфиксе.
Писать конфиги тоже должна машина? Ну тогда дождись skynet и будет тебе счастье.
Ну вот данный конфиг (/etc/passwd) в норме человек руками не пишет.А для тех, которые люди пишут - ты слово "компилировать" и упоминание постфикса пропустил, или где? И да, компиляция подразумевает наличие грамматики, нормального синтаксического разбора и т.п. Поверх этого, в идеале - проход проверки семантики, чтобы несовместимых параметров не было и т.п. - насколько возможно. А дальше приложение пользуется данными в удобном для машины виде, а человек более-менее уверен, что то, что он написал - корректно.
А сейчас, например, в тот же crontab муть вписать - нет проблем, а узнаешь об этом только потом из логов.
P.S. Я AI и так жду с нетерпением, так что скайнетом меня пугать бесполезно :)
Человек /etc/passwd может редактировать и смотреть из него данные. Причем делать это через текстовый редактор куда удобней(хоть и не безопасно), чем через всякие утилиты. Но тут надо отметить, что /etc/passwd это скорее исключение, с учетом его простоты существует даже избыток софта, позволяющий его просмотр и изменение. А вот что делать с конфигом того же апача или exim? Их, представь себе пишут руками.Ну а "компиляция" нужна вовсе не для того, что ты думаешь. Основная ее цель не в проверке правильности, а в минимизации времени старта. В postfix, sendmail или nsd изменения ты все равно вносишь в текстовый конфиг, а не в транслированный вариант. Так что это просто изменение момента парсинга и никаких проблем текстовых конфигов она не решает. Для сведения, очень многие сервисы без всякой "компиляции" позволяют сделать тест конфига на корректность до его применения.
Именно, небезопасно - то есть не должно быть лёгким и удобным. Смотреть данные - никто не мешает держать человекочитаемую копию, если уж так не хочется вызывать тулзу, когда надо глазами посмотреть. вообще, /etc/passwd - это как раз тот случай, когда текстовый конфиг можно выкинуть без какого-либо ущерба, даже с выигрышем. Что и произошло в половине юниксов, собственно.Что до постфикса - корректность синтаксиса там тоже проверяется. И это, как мне кажется, куда важнее, чем скорость запуска. И разумеется, изменения ты вносишь в текстовый вариант. Хотя чисто бинарный конфиг, где принципиально нет проблем ни с каким экранированием, был бы интересен - но слишком у многих условный рефлекс на регэдит включается быстрее логики, чтобы такое можно было спокойно обсуждать. Второй плюс отдельной утилиты - ты никогда не отложишь ошибку парсинга до релоада конфигов.
К тому же компиляция хороша тем, что сервису невозможно подсунуть данные, не прошедшие обработку отдельной утилитой, при разработке которых обычно проверкам уделяется гораздо больше внимания, чем когда парсинг пихается внутрь демона, и это же касается любых сторонних утилит, где разбор обычно ещё хуже. К примеру, как часто вы видели в парсерах конфигов нормальный разбор по грамматике? Обычно какой-то ad-hoc вариант. А ведь одно это избавило бы от массы дыр.
Насчёт Apache - давайте не будем, а? Адски сложный комбайн потребовал адски сложную конфигурацию, которую написать полностью корректно - вообще отдельное искусство, но тут надо говорить скорее о code bloat.
> Потому что цель поста - писание/чтение людьми. А вот цель /etc/passwd, кк
> и кучи других конфигов - в первую очередь чтение машиной. С
> другой стороны, как только в HTML оказывается что-то большое, вроде книги
> - его иногда и компилируют в бинарь - от EPUB до
> PDF.
> Опять же, компиляция в бинарь сто лет как успешно применяется в том
> же постфиксе.В какой такой бинарь в Постфиксе компиляция? Если текстовый список параметров типа transport там используют в другом формате - это не бинарная компиляция, а просто предобработка, а не компилятор конфигов а-ля Cendmail...
>>AUTHOROtto Hammersmith <otto@redhat.com>
Michael K. Johnson <johnsonm@redhat.com>но виноват все равно Марк с убунтой))
Это уязвимость не в Linux, не пугайте народ.
CVE-2015-3290 - в linux
> Проблема проявляется на системах с архитектурой x86_64 при использовании ядра Linux 3.13 и более новых версий.я может что упустил, но где RedHat использует ядра 3.13+? В том же RHEL 7, например, идет 3.10.
Это давняя традиция редхата - бэкпортировать баги из новых ядер.
Вы так пишете, просто чтобы что-то написать? Или специально FUD разводите?
Смотрим https://access.redhat.com/security/cve/CVE-2015-3290This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5 and 6 since they did not backport the nested NMI handler and espfix64 functionalities.
This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 7 and Red Hat Enterprise MRG 2 since they did not backport the espfix64 functionality and also did not backport upstream commit e00b12e64be9a3 that allowed an unprivileged local user to re-enable NMIs from the NMI handler.
>> Это давняя традиция редхата - бэкпортировать баги из новых ядер.
> Вы так пишете, просто чтобы что-то написать? Или специально FUD разводите?Это вообще-то правда -- такая "традиция" действительно есть, увы. Издержки бэкпортов.
Про бэкпорты я знаю :) Я про данный конкретный пример - что за манера у людей вечно подозревать "наверняка же бэкпортнули баг и теперь даже в старой версии ДЫРКА! АХАХАХА!", когда ни одного упоминания, что дырка есть нет и легко находится официальная оценка критичности CVE в плане дистрибутивов RHEL? У редхата вообще с документированием CVE все замечательно, публикуют в открытом доступе, оперативно и подроно.
> я может что упустил, но где RedHat использует ядра 3.13+? В том
> же RHEL 7, например, идет 3.10.первых три абзаца в новости про redhat, четвёртый - про йадро. они не связаны между собой