Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
Сообщение от opennews (??) on 04-Авг-17, 23:02
Группа исследователей из Китайского университета Гонконга выявила (http://openwall.com/lists/oss-security/2017/08/03/2) уязвимость (CVE-2017-7533 (https://security-tracker.debian.org/tracker/CVE-2017-7533)) в ядре Linux, которая может использоваться для повышения своих привилегий в системе. Проблема проявляется начиная с ядра v3.14-rc1 и актуальна вплоть до ядра 4.12. В сети уже распространяется эксплоит для 32-разрядых систем. Для 64-разрядных систем эксплоит пока отсутствует, но теоретически нет преград для его создания. Уязвимость вызвана состоянием гонки между обработкой события inotify и вызовом vfs_rename() в VFS, возникающим при выполнении операции переименования  над тем же файлом. Атакующий может добиться ситуации, при которой после обработки события inotify указатель указывает на новое имя файла, а буфер выделен для старого имени. Соответственно хвост нового имени файла сохраняется за пределами буфера и переписывает данные за границей текущего slab (https://ru.wikipedia.org/wiki/Slab), например, сожет переопределить следующий slab или указатель на список свободных блоков. Уязвимость устранена в Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2...), SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-7533), openSUSE (https://lists.opensuse.org/opensuse-security-announce/2017-0...) и Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1478086). Проблема пока не решена в Debian (https://security-tracker.debian.org/tracker/CVE-2017-7533) и RHEL/CentOS (https://access.redhat.com/security/cve/CVE-2017-7533) (проблема проявляется начиная с Red Hat Enterprise Linux 7.2). В ядре Linux проблема была устранена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) 7 июля без информирования о влиянии исправления на безопасность. URL: http://openwall.com/lists/oss-security/2017/08/03/2 Новость: http://www.opennet.me/opennews/art.shtml?num=46973
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–22 +/–
Сообщение от Аноним (??) on 04-Авг-17, 23:02
Енжой ёр Си.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+17 +/–
	Сообщение от Вареник on 04-Авг-17, 23:07
	Не все уязвимости сводятся к переполнению стека/массива. Гораздо больше логических ошибок, от которых эти ваши ржавчины никак не спасут, только создадут излишние надежды у молодежи - что компиллятор подумает за них.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+4 +/–
	Сообщение от Аноним (??) on 04-Авг-17, 23:10
	> Не все уязвимости сводятся к переполнению стека/массива. Гораздо больше логических ошибок, > от которых эти ваши ржавчины никак не спасут, только создадут излишние > надежды у молодежи - что компиллятор подумает за них. На самом деле желание молодежи меньше работать и больше зарабатывать вполне понятно. В идеале (для программиста), код должен фигак-фигак и в продакшен, и чтобы не надо было поддерживать.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	12. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+4 +/–
	Сообщение от Онтон on 04-Авг-17, 23:45
	Офигенный идеал, зачем тогда погромист, платить ему 200 баксов за весь фигак-фигак, пусть радуется.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	35. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от 564625145 on 05-Авг-17, 08:02
	программисты против языков которые упрощают программирование, так как им платить будут меньше
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	40. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Анонс on 05-Авг-17, 09:10
	Давайте, все настоящие программисты кодят только на асме и ниже.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	65. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Старый одмин on 05-Авг-17, 20:29
	В мои времена программистам платили с доходов компании, и соответственно, чем больше и быстрее работы сделано - тем больше зарплата. Совсем я старый стал...
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	66. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 20:46
	В мои времена им платили по ~120 руб/мес. Белые халаты бесплатно!
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	81. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от kerneliq (ok) on 07-Авг-17, 09:48
	Это сразу после института? Тогда верю
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	87. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от _ (??) on 08-Авг-17, 16:10
	В СССР вообще ИТР-ы получали меньше работяг. Глупость - но факт. Не везде и не всегда, но в среднем по больнице ...
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	34. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 05-Авг-17, 07:53
	> В идеале (для программиста), код должен фигак-фигак и в продакшен, и чтобы > не надо было поддерживать. Написан непограммист. Ты забыл третий ключевой пункт в сфере разработки ПО. Поскольку ты непрограммист ты до него никогда в жизни не догадаешься. А называется он просто -- сопровождение. И как непрограммист ты скорее всего спутаешь это с поддержкой. Вон из профессии!
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	67. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+4 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 20:49
	- Что это вы эту кривую двуногую табуретку везде с собою носите? - Я её не ношу, а сопровождаю!
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	82. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от Аноним (??) on 07-Авг-17, 10:53
	Это приводит к уменьшению заработка
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	41. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+2 +/–
	Сообщение от Ordu (ok) on 05-Авг-17, 10:17
	> Гораздо больше логических ошибок, "А у них негров линчуют", да? Здесь речь про race condition и переполнение буфера, то есть про ошибки которых можно избегать чисто механически, следуя определённым правилам программирования, типа "не использовать unsafe". > только создадут излишние надежды у молодежи Меня вот до сих пор удивляет то, с какой настырностью люди лезут в абсолютно неквалифицированные воспитатели, причём полагая себя умнее воспитуемых. Почему ты полагаешь, что подрастающие поколения настолько тупые, что они не смогут исследовать те ошибки, которые они совершают при написании кода на rust'е и не испытывать бесплодных надежд? То есть вот Вареник может даже не заглядывая в rust осознать, что rust не панацея, а вот подрастающие поколения такие тупые, что понять этого не смогут даже изучая rust, и даже реальное совершение ошибок их ничему не научит. Ну да, поколение ЕГЭ, я знаю. Все умные люди уже родились, Вареник был последним.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	46. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+2 +/–
	Сообщение от Crazy Alex (ok) on 05-Авг-17, 12:24
	Смогли бы... Если пришли к расту, предварительно изучив ассемблер и поработав год-другой на си (и потыкавшись в несколько прежних "серебряных пуль"). Но они ж напрямую норовят лезть, и те вещи, который для сишника очевидны, относят к магии компилятора. Ровно так же нормальный вменяемый джавист, начинавший с более низкого уровня, отлично знает, что именно ему может в джаве прилететь, а тот, который кроме VM ничегоне нюхал - два слова не свяжет о том, какие у той же сборки мусора будут нюансы просто в силу архитектуры. Раст ещё молод, чтобы это было с ним на практике видно, но у нас уже есть PHP, Python, Javascript и Java - там очень наглядно, что используемый язык на количество ошибок влияет очень слабо. А что молодое поколение попустит, когда оно перестанет быть молодым - это называется опыт.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	70. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+6 +/–
	Сообщение от Ordu (ok) on 05-Авг-17, 22:37
	> Смогли бы... Если пришли к расту, предварительно изучив ассемблер и поработав год-другой > на си (и потыкавшись в несколько прежних "серебряных пуль"). Но они > ж напрямую норовят лезть, и те вещи, который для сишника очевидны, > относят к магии компилятора. Я не могу говорить определённо в силу отсутствия фактов -- раст действительно молодой язык, -- но всё же мне кажется, что растового понимания указателей, ссылок и памяти вполне достаточно для того, чтобы реально понимать происходящее. В том смысле, что можно изучать как это всё работает, кувыркаясь с C и заглядывая в асм код, и создать в своей голове понимание достойное какого-нибудь там Линуса Торвальдса, а можно достигнуть того же самого, заменив C на rust. Rust реально очень недалеко ушёл от C в том смысле, что именно он делает за программиста. Он далеко ушёл в объёмах того, что он _не_позволяет_ делать программисту. Правда это с моей точки зрения, то есть с точки зрения человека, который многие вещи давным давно считает самоочевидными и не заслуживающими внимания. Эти вещи при этом могут быть неочевидными и требующими весьма пристального внимания в процессе обучения. > прежних "серебряных пуль" Мне не очень нравится сравнение rust'а с серебряной пулей. Мне он больше напоминает серебряную очередь из пулемёта. В том смысле, что там нельзя выделать какую-то одну идею, которая может претендовать на роль серебряной пули, там очень много чего есть, начиная естественно с системы типов, продолжая, например, типами Result и Carrier для структурной обработки ошибок, и заканчивая тем как организован процесс исследования путей дальнейшего развития rust'а, разработка rust'а и его документирование. Не последнюю роль играет и пакетный менагер при rust: одна из вещей, которую людям приходящим из C/C++ приходится менять в своей голове, для того чтобы освоить rust -- это отношение к депендансам. В C/C++ принято всё писать вручную, подключая дополнительные библиотеки только тогда, когда это сэкономит больше недели напряжённого кодинга, иначе овчинка выделки не стоит. В rust'е я могу засунуть в депендансы пакет содержащий один макрос, который я бы сам написал за час-два, и нисколько не париться на этот счёт. Излишняя увлечённость тем, чтобы писать максимум своими руками, тоже ведёт к повышению количества ошибок. > Раст ещё молод, чтобы это было с ним на практике видно, но > у нас уже есть PHP, Python, Javascript и Java - там > очень наглядно, что используемый язык на количество ошибок влияет очень слабо. Я не уверен, что такое сравнение имеет смысл, без глубокой рефлексии на предмет того, чего пытались достичь, отливая ту или иную серебряную пулю, что они получили на самом деле и что было упущено, какие ошибки были совершены, что пуля оказалась не серебряной. Да, все предыдущие попытки сделать более безопасный язык оказались провальными, из чего напрашивается сделать вывод по индукции, что и все будущие ошибки кончат тем же. Но из этого напрашивается ещё один вывод: не стоит даже заморачиваться разрабатывать новые языки, ни в практическом плане, ни в теоретическом. А это уже пахнет для меня махровым консерватизмом и всепроникающей духовностью. И я вижу единственный способ примирить логику с обонянием: считать что индукция в данном случае -- неверный способ рассуждений. В конце-концов, индукция стопроцентов работает только в математике, в виде матиндукции. Даже в физике, которая ближе всего остального к математике, индукция работает не всегда, и иногда выясняется, что уже открытые законы физики надо исправлять. Нассим Талеб даже своего Чёрного Лебедя написал специально для того, чтобы обозначить проблему. Поэтому я не вижу ничего плохого в том, чтобы иногда положить на индукцию с прибором. А если я кладу на индукцию с прибором, то rust -- это лучший сегодняшний кандидат на создание безопасной замены для C. Более того, я ужасно раздасадован самонадеянными разработчиками D, которые свой язык назвали этой самой буквой. Потому что если глянуть на последовательность B -> C -> C++ -> ???, то rust отлично вписывается на роль того, кого надо было бы поставить следом за C++, если рассмотреть C++ как процесс выполнения инкремента. Но эти любители высокоуровневого кодинга всё испортили. С другой стороны ржавчина, корродирующая мозги людей так, что вылезает наружу и начинает корродировать[1] всё остальное, вплоть до ls[2], тоже довольно метафорична. Меня это тоже заразило, я тоже сижу и переписываю избранную мною C'шную программу на rust -- это настолько fun, что меня даже не волнует бессмысленность этого процесса и ненужность программы. [1] https://github.com/jameysharp/corrode [2] https://the.exa.website/
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	91. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от pripolz on 11-Авг-17, 17:20
	> считать что индукция в данном случае -- неверный способ рассуждений Тут верный способ рассуждений такой: а кому ВЫГОДНО вкладываться в развитие Rust/Go/D ? Приведу пример: MS Visual Studio принципиально не поддерживает стандарт C11 до сих пор.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	92. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Ordu (ok) on 11-Авг-17, 19:46
	> Тут верный способ рассуждений такой: а кому ВЫГОДНО вкладываться в развитие Rust/Go/D ? Не совсем так. Выгодно всем, кто хоть немного в теме. Вопрос в том, кто вкладывается. > Приведу пример: MS Visual Studio принципиально не поддерживает стандарт C11 до сих > пор. А майкрософтовский C++ компилятор ещё жив? Ну, в смысле, есть gcc, есть llvm, зачем кому-нибудь может быть нужен майкрософтовский компилятор? Если нужен MSVS, то проще ведь воткнуть llvm в MSVS и не париться на этот счёт больше никогда. То есть, я не в курсе на самом деле, писать какой-либо код под венду я не пытался очень давно и очень давно не интересовался как это надо делать. Может быть там все давно перешли писать на паскале, а я и не заметил. Вообще же это майкрософт в её стиле. Если MS занимается поддержкой какой-нибудь не своей технологии, то исключительно с целью перетянуть одеяло на себя. С C++ им особо ничего не светит в их понимании света. Поэтому они не будут заморачиваться поддерживать какие-то там стандарты C++. MS никогда особо с C++ не дружила: win32api наваян на C, а не на C++. Они потом пытались MFC протолкнуть, но это был один из самых неудачных их экспериментов, на мой взгляд, там даже маркетинг не особо помог, и они переключились на .NET и C#. Если же попытаться предсказывать будущее... У меня чай так себе (я чёт последнее время расслабился, и меня жаба душит покупать действительно хороший чай) я не уверен, что принцессе нури можно доверять. Но её чаинки говорят... Ща, очки одену... Да, они говорят, что MS ещё несколько лет понаблюдает за тем, что сегодня творится с языками программирования, выберет те перки, которые ей понравятся и выкатит либо новый язык для .NET, либо даже объявит .NET устаревшим и выкатит совершенно новый стек технологий, и скажет, что это самая распоследняя и наисовременнейшая технология, которой нет аналогов в мировом производстве.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	50. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от eganru on 05-Авг-17, 15:05
	[i]чисто механически, следуя определённым правилам программирования, типа "не использовать unsafe"[/i] - не могу осознать, каким образом unsafe связан c состоянием гонки в данном случае? я не знаю rust и интересно, каким образом он помогает избегать состояний гонки.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	54. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от pda on 05-Авг-17, 16:03
	Rust не позволить написать код, который одложит указатель в событие inotigy и одновременно даст другому куску кода владеть им с правом на запись.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	55. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+2 +/–
	Сообщение от Ordu (ok) on 05-Авг-17, 17:06
	> [i]чисто механически, следуя определённым правилам программирования, типа "не использовать > unsafe"[/i] - не могу осознать, каким образом unsafe связан c состоянием > гонки в данном случае? > я не знаю rust и интересно, каким образом он помогает избегать состояний > гонки. Я сейчас потратил полчаса пытаясь изобрести краткое объяснение. Мне не удалось это. Там вся магия сокрыта в системе типов с лайфтаймами и borrowing'е, и мне кажется, что единственный способ понять как это работает -- это взять и попытаться создать race condition в rust'е. Если потратить несколько дней на борьбу с borrow checker'ом, пробуя объехать его на кривой козе и так, и эдак, то в голове начинает зарождаться понимание, почему race condition невозможен. Если потратить ещё месяц на то, чтобы читать статьи и чужой код, то можно понять как, несмотря на всё это, возможно писать какой-нибудь рабочий и полезный код. Но так или иначе, чтобы понять как это работает, надо рассмотреть десяток примеров с потенциальным race condition, разбирая каждый на предмет "а если попытаться так, то ничего не получиться потому-то и потому-то", и завершая это сентенцией типа "таким образом у нас есть такие-то пути справится с проблемой, этот лучше в таких-то ситуациях, а этот в таких-то". Но чтобы не звучать совсем абстрактно, я приведу один пример. Если у меня есть struct Dummy {     a: u32,     b: u32, } Допустим я хочу чтобы для этой структуры всегда выполнялся бы какой-нибудь инвариант, например, a = 2*b. Допустим, я напишу функцию: fn double_this_dummy(dummy: &mut Dummy) {     dummy.a *= 2;     dummy.b *= 2; } Инвариант сохраняется. Можно предположить, что параллельный поток в это время изменит именно этот объект, вот ровно между удвоением a и b он возьмёт и уменьшит a на 3 и b на 6. Тогда инвариант будет нарушен. Но rust не позволит мне создать две mutable ссылки на этот объект, поэтому если внутри этой функции у меня есть ссылка на dummy, то у параллельного потока её не будет. А значит никакого race condition'а не случится. Если мы попытаемся таки создать две mutable ссылки на один и тот же объект, так чтобы одна была в одном потоке, а другая в другом, то это выльется в долгий сеанс переругивания с borrow-checker'ом, и кончится либо использованием unsafe кода, либо осознанием своей глупости и нахождением safe пути достичь наших целей. Сложно объяснить как это происходит -- это надо испытать на себе.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	60. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от egan_ru on 05-Авг-17, 18:05
	спасибо. в общих чертах понял.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	94. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от Аноним (??) on 15-Авг-17, 12:33
	Это все простейшие примеры. А логические гонки, когда, например (первое что пришло, сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, а второй поток начинает читать от туда, но первый ещё не досохранял. Такое вот rust никак не отследит. А то что у вас, это просто переменная в памяти, которая в двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, случайно где-нибудь наступить можно.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	95. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 15-Авг-17, 12:35
	> Это все простейшие примеры. А логические гонки, когда, например (первое что пришло, > сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, > а второй поток начинает читать от туда, но первый ещё не > досохранял. Такое вот rust никак не отследит. > А то что у вас, это просто переменная в памяти, которая в > двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, > случайно где-нибудь наступить можно. При всём при этом, возникает вопрос, придется ли мучится, если реально логикой эти потоки разделены, то есть одновременное выполнение кода не возможно, потому что второй поток уснул в ожидание. Я так понял, rust за такое будет пинать
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	97. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Ordu (ok) on 15-Авг-17, 19:29
	>[оверквотинг удален] >> сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, >> а второй поток начинает читать от туда, но первый ещё не >> досохранял. Такое вот rust никак не отследит. >> А то что у вас, это просто переменная в памяти, которая в >> двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, >> случайно где-нибудь наступить можно. > При всём при этом, возникает вопрос, придется ли мучится, если реально логикой > эти потоки разделены, то есть одновременное выполнение кода не возможно, потому > что второй поток уснул в ожидание. Я так понял, rust за > такое будет пинать На такие случаи есть RefCell. RefCell сам по себе immutable объект (а значит можно одновременно иметь много ссылок на него), но если его попросить, то он выдаст mutable ссылку на содержащийся в нём объект. При этом он выполнит в рантайме проверки того, что в любой момент времени существует только одна mutable ссылка на объект. По сути, этот RefCell -- это те же проверки, которые выполняет компилятор, отличие в том, что они выполняются в рантайме, а не во время компиляции. Если логические допущения о том, что одновременное выполнение кода невозможно, окажутся неверными, то поток вывалится в панику.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	96. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Ordu (ok) on 15-Авг-17, 19:24
	> Это все простейшие примеры. А логические гонки, когда, например (первое что пришло, > сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, > а второй поток начинает читать от туда, но первый ещё не > досохранял. Такое вот rust никак не отследит. Чем эта гонка "логическая"? Чтобы читать в или писать из File нужна mutable ссылка на этот File. Но rust запрещает иметь две mutable ссылки. В зависимости от того, каким образом вы попытаетесь создать две такие ссылки в разных потоках, вы получите либо ошибку компиляции, либо падение одного из потока в панику в описываемой ситуации, либо блокирование одного потока до завершения операции в другом. Другое дело, что потоки могут независимо придти к выводу, что файл надо открыть и что-то с ним сделать, и у них будет два разных объекта File. И да, от этого rust не защитит. Но в этом случае, race происходит _вне_ rust'а. Здесь же речь идёт о _memory_ safety. > А то что у вас, это просто переменная в памяти, которая в > двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, > случайно где-нибудь наступить можно. Да, проходят в школе. И здесь я изложил самые-самые азы и то не полностью. О чём я кстати даже предупредил. Совершенно не удивительно, что тот единственный пример, который я привёл, оказался таким, который "проходят в школе". Или вы всё же полагаете, что мне следовало написать здесь целую книгу, сопроводив её десятком искусственных примеров, и несколькими десятками реальных, надёрганных из разных проектов на github'е?
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	5. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+8 +/–
	Сообщение от Аноним (??) on 04-Авг-17, 23:07
	Что-то по поделкам на пыхе статистика не лучше. Пожалуй, даже хуже. Эдак на пару порядков. Хотя казалось бы - автоматическое управление памятью, GC, все дела.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	83. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 07-Авг-17, 10:58
	> Что-то по поделкам на пыхе статистика не лучше. Пожалуй, даже хуже. Эдак > на пару порядков. > Хотя казалось бы - автоматическое управление памятью, GC, все дела. М... а с какой версии пых стал многопоточным?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	11. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 04-Авг-17, 23:43
	Давай, расскажи нам, какие языки позволяют избежать гонки.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	17. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+2 +/–
	Сообщение от анонимус (??) on 05-Авг-17, 00:15
	хаскель с STM
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	21. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+5 +/–
	Сообщение от irinat (ok) on 05-Авг-17, 00:54
	Как ни странно, Rust. Концепция владения и заимствования нацелена на разделение ресурсов и предотвращение гонок. Но если хочется, всегда есть unsafe.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	26. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+3 +/–
	Сообщение от angra (ok) on 05-Авг-17, 03:36
	Правильнее было бы сказать, что Rust позволяет предотвратить больше вариантов race condition, чем C. Но защитить от вобще всех вариантов race condition он само собой не может.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	51. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Crazy Alex (ok) on 05-Авг-17, 15:33
	По идее он только от чего-то совсем тривиального сможет защитить - ценой довольно основательных неудобств для программиста. Стоит ли оно того - лет через пять-семь увидим...
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	61. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от irinat (ok) on 05-Авг-17, 18:40
	Просто не нужно писать Си-код на Rust. Так-то программисты могут писать фортран-программы на любом языке программирования. Просто так делать не стоит.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	64. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аномномномнимус on 05-Авг-17, 19:58
	yet another "просто не нужно писать код, если он не идеальный", только со своей колокольней, куликами и болотом, ага
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	48. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Crazy Alex (ok) on 05-Авг-17, 12:27
	Те, которые многопоточность толкмо не могут, конечно. В остальных - в крайнем случае для гонки понадобится ошибка в реализации среды. Чудес не бывает.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	98. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Очередной аноним on 18-Авг-17, 11:26
	> Давай, расскажи нам, какие языки позволяют избежать гонки. Тот же D. Все "обычные" переменные локальны для потоков. Т.е. если ты объявишь "int a;" то в D это будет не глобальная переменная, которую может крутить каждый поток, конкурируя с соперниками. В D каждый поток получит свою копию этой переменной, которая будет храниться в TLS (thread-local storage). Если же тебе кровь из носу понадобится разделять её между потоками, то ты ее объявляешь разделяемой - "shared int a;". И компилятор теперь знает, что она разделяется между потоками и запретит тебе совершать над ней опасные, не синхронизированные, действия. Т.е. ты не сможешь тупо сделать "++a;", компилятор ругнется. Для этого  тебе придется использовать специальные атомарные примитивы из модуля std.concurrency для исключения одновременного незащищенного доступа. И вообще, там (в D) для взаимодействия потоков побуждают использовать подсистему сообщений, максимально локализуя, обособляя потоки друг от друга. Взаимодействие через разделяемые данные (которые с квалификатором shared и конечно с помощью мьютексов и прочего из std.concurrency)  оправданно только если объемы этих данных большие и копирование их в виде сообщений накладно.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	93. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от Аноним (??) on 13-Авг-17, 18:48
	>  Енжой ёр Си. А что, есть ЯП где гонки невозможно сделать принципиально?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–5 +/–
Сообщение от Michael Shigorin (ok) on 04-Авг-17, 23:04
А не слили 32-битный в качестве демки? (так вот о чём наши ядерщики на этой неделе говорили)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
Сообщение от Аноним (??) on 04-Авг-17, 23:04
> В ядре Linux проблема была устранена 7 июля без информирования о влиянии исправления на безопасность. Не тому человеку дали Pwnie Awards, ой не тому.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Аноним (??) on 04-Авг-17, 23:14
	Линус, помнится, вообще говорил, что уязвимости ничем от других ошибок не отличаются, и никаких специальных мер (отметки как уязвимости, приоритета при исправлении, уведомления вендоров и т.д.) нафиг не нужно. Исправлять только в порядке общей очереди.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	56. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 17:12
	Прям Доктор Манхеттен.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
Сообщение от Ergil (ok) on 04-Авг-17, 23:32
Как хорош все же canonical-livepatch. uptime 343 days А CVE-2017-7533 закрыт, как и все прочие. Сколько бы виндовые хомячки лора и опеннета не визжали, а на реальных серверах Ubuntu прекрасна.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+3 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 00:05
	Сейчас бы в 2017 аптаймом меряться. P.S. Недавно без сожалений ребутнул серер точного времени с аптаймом > 5 лет.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	16. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+7 +/–
	Сообщение от Crazy Alex (ok) on 05-Авг-17, 00:10
	Я в прицнипе не спорю, но аптайм - пофиг. Если доступность действительно важна - значит, есть резервирование и последовательная перезагрузка - не проблема. Если резервирования нет - значит, не надо, и перезагрузка тоже не проблема.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	45. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+4 +/–
	Сообщение от пох on 05-Авг-17, 12:19
	еще бывает банальное - "доступность важна, но денег на полноценный резерв нет и не будет, есть только аварийные системы". но вообще-то лучше систем с аптаймами в годы избегать - рано или поздно оно случайно перезагрузится (причем не во время тихое, а в самый неподходящий момент), и тут выяснится, что два года назад что-то руками поправили, но при перезагрузке оно слетает, или наоборот, что-то поменяли, в том числе стартовые скрипты, а оно с ошибкой и ключевой сервис вообще не запускается. как ни старайся быть аккуратным - все равно что-нибудь упустишь. А поскольку с момента исправления прошли десятки месяцев - не так уже и просто выяснить, кто, чего и зачем там трогал. и это не говоря уже о том, какие прелестные возможности live patch предоставляет для прятанья следов pwning.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	52. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Crazy Alex (ok) on 05-Авг-17, 15:39
	Это называется "админ считает, что доступность важна, менеджер - что нет". Бывает, ну там там жизнь покажет, кто из них прав (кстати, менеджеры оказываются правы гораздо чаще, чем кажется админам с программистами). А вот насчёт забытых настроек и подобного - поддерживаю обеими руками. Причём ещё окажется, что владельца тайного знания год как нет. Примерно за это я люблю подход "что-то умерло - снести, врубить резерв" и прочие модные штуки вроде контейнеров, stateless-микросервисов и подобного  - очень способствует переносу знаний из головы в конфигурацию.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	73. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от пох on 06-Авг-17, 13:07
	> Это называется "админ считает, что доступность важна, менеджер - что нет". есть еще распространенный вариант - "вы же специалисты, сделайте нам бесплатно". кто у нас там - банк разрытие вчерась навернулся, поскольку ниасилил резервную опту себе в датацентр (именно вот в момент, когда щисливые клиенты и без того обдумывают житье - то ли снять все вклады не взирая на штрафы, то ли снять все вклады и еще и текущий счет закрыть, и когда любой ценой надо изображать стабильность)? (на самом деле еще и аван-гад туда же, но те быстро оклемались, часа два только ничего не работало)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	25. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от asdsdsa on 05-Авг-17, 01:50
	Я вам просто напомню: http://www.opennet.me/opennews/art.shtml?num=36401
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

13. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–2 +/–
Сообщение от Sfinx (ok) on 04-Авг-17, 23:50
и где ссыль на exploit ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+12 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 00:35
	Сказал же, что уязвимость локальная — вот и ищите на http://127.0.0.1/
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	20. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 05-Авг-17, 00:49
	Недоступно... http://hnng.moe/f/T9s
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	22. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 05-Авг-17, 00:55
	Судя по скриншоту, локализация тоже полетела, так что, похоже, проблемы глобальные. Советую перепрошить и потом попробовать снова.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	24. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+2 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 00:56
	> Судя по скриншоту, локализация тоже полетела, так что, похоже, проблемы глобальные. Советую перепрошить и потом попробовать снова. Вы не видели ua_UA.UTF-8 похоже.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	42. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 10:36
	>> Судя по скриншоту, локализация тоже полетела, так что, похоже, проблемы глобальные. Советую перепрошить и потом попробовать снова. > Вы не видели ua_UA.UTF-8 похоже. Нет, это кое-кому отказало чувство юмора. Не говоря о том, что ru_RU.UTF-8 и en_US.UTF-8 будут выглядеть точно также в данном случае.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	59. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 17:29
	> Нет, это кое-кому отказало чувство юмора. А если чувства юмора у человека нет и не было? > Не говоря о том, что ru_RU.UTF-8 и en_US.UTF-8 будут выглядеть точно также в данном случае. Прошу прощения, но если вы генерируете страницу по локали то не обязательно будут использоваться две.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	23. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 00:55
	Типичный User@localhost.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	49. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–2 +/–
	Сообщение от Sfinx (ok) on 05-Авг-17, 13:20
	вопрос был не об уязвимости а оссылке на exploit. чукча типа писатель..
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	75. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Мегазаычы on 06-Авг-17, 15:49
	а зачем тебе? комиттеры в апстрим ядро и мэйнтэйнеры дистрибутивов получили репродюсер, доказывающий что уязвимость есть и об который они тестировали фиксы. а остальным профанам зачем? хочешь эксплойт - пиши эксплойт, механизм гонки раскрыт, ничо там сложного нет, такой же рэйс как десяток других. не умеешь в си и внутренние структуры ядра - сиди обтекай или покупай в даркнете.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

18. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
Сообщение от Аноним (??) on 05-Авг-17, 00:26
>В ядре Linux проблема была устранена 7 июля без информирования о влиянии исправления на безопасность. крутой подход, мейнстримный, денежный
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
Сообщение от Аноним (??) on 05-Авг-17, 08:12
> В ядре Linux проблема была устранена 7 июля без информирования о влиянии исправления на безопасность. Пишите плиз корректно. Человек делал глобальный cleanup - и случайно зацепил и эту проблему, даже наверно не задумываясь о том что это такое.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+2 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 08:29
	> Пишите плиз корректно. Человек делал глобальный cleanup - и случайно зацепил и эту проблему, даже наверно не задумываясь о том что это такое. Ничего подобного, в багтрекере Red Hat сведения об уязвимости появились 6 июля, за день до исправления. Но до позавчерашнего дня доступ к описанию бага был закрыт. https://bugzilla.redhat.com/show_activity.cgi?id=1468283 Pedro Sampaio     2017-07-06 10:55:10 EDT     CC         security-response-team ... Vladis Dronov     2017-08-03 10:32:23 EDT     Whiteboard А к багу https://bugzilla.redhat.com/show_bug.cgi?id=1468288 до сих пор не открыли доступ.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

39. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
Сообщение от Аноним (??) on 05-Авг-17, 09:02
> Уязвимость устранена в Ubuntu > Проблема пока не решена в Debian Дыра в системе? Пустяки, стабильность важнее.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–4 +/–
	Сообщение от пох on 05-Авг-17, 12:24
	>> Уязвимость устранена в Ubuntu >> Проблема пока не решена в Debian > Дыра в системе? Пустяки, стабильность важнее. у вас просто недостаточно стабильный дебиан - в позапрошлой версии ядро без этого бага. ну а что дебиановцы не умели и не умеют самостоятельно поддерживать ядра, как бе и не новость ни разу. Двустрочные патчи бэкпортят неделями, а если, ненароком, там не все делается копипастой, то можно и пару месяцев подождать. Стабильность... кого не устраивает - берет и сам себе ставит vanilla ядро поновее - тем более что родное-"стабильное" от vanilla обычно ничем полезным не отличается, это вам не rh с ее тремя сотнями патчей.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	58. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от бедный буратино (ok) on 05-Авг-17, 17:22
	> тем более что родное-"стабильное" от vanilla обычно ничем полезным не отличается, это вам не rh с ее тремя сотнями патчей. действительно, это не rh с тремя сотнями патчей на штатное ядро Debian 8 сейчас идут 730 патчей, на штатное ядро Debian 9 - 458
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	68. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от Аноним (??) on 05-Авг-17, 20:53
	а не хотите 15к патчей у шапки ?
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	69. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от бедный буратино (ok) on 05-Авг-17, 21:15
	я говорю про *целых триста патчей* :)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	71. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 06-Авг-17, 09:16
	ах простите. Это ваш оппонент туфту гонит. В 7.3 было ~16k патчей - включая цельнотянутый сетевой стек от ~4.8.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	74. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от пох on 06-Авг-17, 13:25
	> а не хотите 15к патчей у шапки ? как и у дебиана, большую часть можно просто выкинуть без вреда для себя. Драйвера чего-нибудь, чего у тебя никогда не будет, или исправления чего-то вроде s360. остальное либо бэкпорты (то есть vanilla как минимум не хуже), либо что-то совсем странное. все же, если их отбросить, останется около трех сотен, которые уже просто так не отбросишь - либо исправляют что-то, без чего вообще-то жить нехорошо, либо лезут в такие потроха системы, что нужно слишком много лишних знаний, чтобы оценить их нужность/ненужность. В частности, пресловутый рут для n_tty.c был тихо исправлен за пару лет до общего шухера. Причем не так, как сейчас в vanilla, там больше покрыто локами. А в дебиане как-то ни разу ничего ценного не попадалось, одни копипасты из lk. Я, правда, девятый не видел и не планирую заглядывать, но что-то сильно сомневаюсь, что там откуда-то взялся мега-девелопер.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	76. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Мегазаычы on 06-Авг-17, 15:54
	>  Драйвера чего-нибудь, чего у тебя никогда не будет, или исправления > чего-то вроде s360. это у тебя s360x никогда не будет и, возможно, даже юзерского шелла в такую систему. а клиенты с такими системами заплатили денег (которых у тебя, возможно, тоже никогда не будет) за патчи, который им нужны и важны.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	78. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
	Сообщение от пох on 06-Авг-17, 22:15
	> а клиенты с такими системами заплатили денег ну, необязательно, есть же "бесплатный" debian systemZ (это ж вроде 390 и есть) - и даже, видимо, кому-то из разработчиков шелл на ней даден. Чтоб денех никому не платить, ага ;-) хотя я с большим трудом представляю себе контингент пользователей данной комбинации. (впрочем, вполне возможно, что это, + SLES и кто там есть еще - это одна и та же s390 - и что она вообще на свете осталась такая одна ;-)
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

63. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–1 +/–
Сообщение от anonymous (??) on 05-Авг-17, 18:46
с inotify нельзя указать каталог и получать события при изменении любого подкаталога и файла в любом подкаталоге и это плохо, приходится сканировать все каталоги и их слушать(((
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	72. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 06-Авг-17, 09:16
	> с inotify нельзя указать каталог и получать события при изменении любого подкаталога > и файла в любом подкаталоге и это плохо, приходится сканировать все > каталоги и их слушать((( вроде была фича наследования флагов и подъема события по каталогам вверх..
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	77. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+1 +/–
	Сообщение от Мегазаычы on 06-Авг-17, 15:56
	> с inotify нельзя указать каталог и получать события при изменении любого подкаталога > и файла в любом подкаталоге и это плохо это не плохо, это защита от идиотов(-разработчиков). представь, что кто-то вешает inotify на /
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	79. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–2 +/–
	Сообщение от Аноним (??) on 06-Авг-17, 23:29
	Почему вешать inotify на / это плохо?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	80. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+2 +/–
	Сообщение от Led (ok) on 07-Авг-17, 01:47
	> Почему вешать inotify на / это плохо? Вовсе не плохо. Продолжай перебегать улицу на красный свет и "вешать inotify на /" - тебе можно.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	84. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Аноним (??) on 07-Авг-17, 11:20
	Почему перебегать улицу на красный свет плохо, мне объясняли. Почему вешать inotify на / плохо, мне не объясняли.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	88. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от _ (??) on 08-Авг-17, 16:51
	Учить дураков - тяжкий труд. Труд, согласно Конституции, должен быть оплачен. Тяжкий труд должен быть оплачен хорошо. Выставляй своё предложение в Jobs, я думаю за тыщщу кто нить согласится, по е-мэйлу. (Я - нет)
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	89. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Led (ok) on 08-Авг-17, 21:31
	> Почему перебегать улицу на красный свет плохо, мне объясняли. Для будущего асфальторовнятеля в модной оранжевой робе этого достаточно.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

85. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	–2 +/–
Сообщение от Sylvia (ok) on 07-Авг-17, 12:15
>В ядре Linux проблема была устранена 7 июля без информирования о влиянии исправления на безопасность. вот только ядра с этим коммитом вышли только вчера (4.12.5) и сегодня (4.9.41 4.4.80 ...)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	86. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Led (ok) on 07-Авг-17, 23:21
	> вот только ядра с этим коммитом вышли только вчера (4.12.5) и сегодня > (4.9.41 4.4.80 ...) Так это для гентушников. Для остальных давно вышли...
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема