Группа исследователей из Китайского университета Гонконга выявила (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
Енжой ёр Си.
Не все уязвимости сводятся к переполнению стека/массива. Гораздо больше логических ошибок, от которых эти ваши ржавчины никак не спасут, только создадут излишние надежды у молодежи - что компиллятор подумает за них.
> Не все уязвимости сводятся к переполнению стека/массива. Гораздо больше логических ошибок,
> от которых эти ваши ржавчины никак не спасут, только создадут излишние
> надежды у молодежи - что компиллятор подумает за них.На самом деле желание молодежи меньше работать и больше зарабатывать вполне понятно.
В идеале (для программиста), код должен фигак-фигак и в продакшен, и чтобы не надо было поддерживать.
Офигенный идеал, зачем тогда погромист, платить ему 200 баксов за весь фигак-фигак, пусть радуется.
программисты против языков которые упрощают программирование, так как им платить будут меньше
Давайте, все настоящие программисты кодят только на асме и ниже.
В мои времена программистам платили с доходов компании, и соответственно, чем больше и быстрее работы сделано - тем больше зарплата.
Совсем я старый стал...
В мои времена им платили по ~120 руб/мес. Белые халаты бесплатно!
Это сразу после института? Тогда верю
В СССР вообще ИТР-ы получали меньше работяг. Глупость - но факт. Не везде и не всегда, но в среднем по больнице ...
> В идеале (для программиста), код должен фигак-фигак и в продакшен, и чтобы
> не надо было поддерживать.Написан непограммист. Ты забыл третий ключевой пункт в сфере разработки ПО. Поскольку ты непрограммист ты до него никогда в жизни не догадаешься. А называется он просто -- сопровождение. И как непрограммист ты скорее всего спутаешь это с поддержкой. Вон из профессии!
- Что это вы эту кривую двуногую табуретку везде с собою носите?
- Я её не ношу, а сопровождаю!
Это приводит к уменьшению заработка
> Гораздо больше логических ошибок,"А у них негров линчуют", да? Здесь речь про race condition и переполнение буфера, то есть про ошибки которых можно избегать чисто механически, следуя определённым правилам программирования, типа "не использовать unsafe".
> только создадут излишние надежды у молодежи
Меня вот до сих пор удивляет то, с какой настырностью люди лезут в абсолютно неквалифицированные воспитатели, причём полагая себя умнее воспитуемых. Почему ты полагаешь, что подрастающие поколения настолько тупые, что они не смогут исследовать те ошибки, которые они совершают при написании кода на rust'е и не испытывать бесплодных надежд? То есть вот Вареник может даже не заглядывая в rust осознать, что rust не панацея, а вот подрастающие поколения такие тупые, что понять этого не смогут даже изучая rust, и даже реальное совершение ошибок их ничему не научит. Ну да, поколение ЕГЭ, я знаю. Все умные люди уже родились, Вареник был последним.
Смогли бы... Если пришли к расту, предварительно изучив ассемблер и поработав год-другой на си (и потыкавшись в несколько прежних "серебряных пуль"). Но они ж напрямую норовят лезть, и те вещи, который для сишника очевидны, относят к магии компилятора. Ровно так же нормальный вменяемый джавист, начинавший с более низкого уровня, отлично знает, что именно ему может в джаве прилететь, а тот, который кроме VM ничегоне нюхал - два слова не свяжет о том, какие у той же сборки мусора будут нюансы просто в силу архитектуры.Раст ещё молод, чтобы это было с ним на практике видно, но у нас уже есть PHP, Python, Javascript и Java - там очень наглядно, что используемый язык на количество ошибок влияет очень слабо.
А что молодое поколение попустит, когда оно перестанет быть молодым - это называется опыт.
> Смогли бы... Если пришли к расту, предварительно изучив ассемблер и поработав год-другой
> на си (и потыкавшись в несколько прежних "серебряных пуль"). Но они
> ж напрямую норовят лезть, и те вещи, который для сишника очевидны,
> относят к магии компилятора.Я не могу говорить определённо в силу отсутствия фактов -- раст действительно молодой язык, -- но всё же мне кажется, что растового понимания указателей, ссылок и памяти вполне достаточно для того, чтобы реально понимать происходящее. В том смысле, что можно изучать как это всё работает, кувыркаясь с 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/
> считать что индукция в данном случае -- неверный способ рассужденийТут верный способ рассуждений такой: а кому ВЫГОДНО вкладываться в развитие Rust/Go/D ?
Приведу пример: MS Visual Studio принципиально не поддерживает стандарт C11 до сих пор.
> Тут верный способ рассуждений такой: а кому ВЫГОДНО вкладываться в развитие 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 устаревшим и выкатит совершенно новый стек технологий, и скажет, что это самая распоследняя и наисовременнейшая технология, которой нет аналогов в мировом производстве.
чисто механически, следуя определённым правилам программирования, типа "не использовать unsafe" - не могу осознать, каким образом unsafe связан c состоянием гонки в данном случае?
я не знаю rust и интересно, каким образом он помогает избегать состояний гонки.
Rust не позволить написать код, который одложит указатель в событие inotigy и одновременно даст другому куску кода владеть им с правом на запись.
> чисто механически, следуя определённым правилам программирования, типа "не использовать
> unsafe" - не могу осознать, каким образом 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 пути достичь наших целей. Сложно объяснить как это происходит -- это надо испытать на себе.
спасибо. в общих чертах понял.
Это все простейшие примеры. А логические гонки, когда, например (первое что пришло, сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, а второй поток начинает читать от туда, но первый ещё не досохранял. Такое вот rust никак не отследит.А то что у вас, это просто переменная в памяти, которая в двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, случайно где-нибудь наступить можно.
> Это все простейшие примеры. А логические гонки, когда, например (первое что пришло,
> сильно надуманно, но думаю степень можно опять), мы сохраняем на диск,
> а второй поток начинает читать от туда, но первый ещё не
> досохранял. Такое вот rust никак не отследит.
> А то что у вас, это просто переменная в памяти, которая в
> двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю,
> случайно где-нибудь наступить можно.При всём при этом, возникает вопрос, придется ли мучится, если реально логикой эти потоки разделены, то есть одновременное выполнение кода не возможно, потому что второй поток уснул в ожидание. Я так понял, rust за такое будет пинать
>[оверквотинг удален]
>> сильно надуманно, но думаю степень можно опять), мы сохраняем на диск,
>> а второй поток начинает читать от туда, но первый ещё не
>> досохранял. Такое вот rust никак не отследит.
>> А то что у вас, это просто переменная в памяти, которая в
>> двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю,
>> случайно где-нибудь наступить можно.
> При всём при этом, возникает вопрос, придется ли мучится, если реально логикой
> эти потоки разделены, то есть одновременное выполнение кода не возможно, потому
> что второй поток уснул в ожидание. Я так понял, rust за
> такое будет пинатьНа такие случаи есть RefCell. RefCell сам по себе immutable объект (а значит можно одновременно иметь много ссылок на него), но если его попросить, то он выдаст mutable ссылку на содержащийся в нём объект. При этом он выполнит в рантайме проверки того, что в любой момент времени существует только одна mutable ссылка на объект. По сути, этот RefCell -- это те же проверки, которые выполняет компилятор, отличие в том, что они выполняются в рантайме, а не во время компиляции. Если логические допущения о том, что одновременное выполнение кода невозможно, окажутся неверными, то поток вывалится в панику.
> Это все простейшие примеры. А логические гонки, когда, например (первое что пришло,
> сильно надуманно, но думаю степень можно опять), мы сохраняем на диск,
> а второй поток начинает читать от туда, но первый ещё не
> досохранял. Такое вот rust никак не отследит.Чем эта гонка "логическая"? Чтобы читать в или писать из File нужна mutable ссылка на этот File. Но rust запрещает иметь две mutable ссылки. В зависимости от того, каким образом вы попытаетесь создать две такие ссылки в разных потоках, вы получите либо ошибку компиляции, либо падение одного из потока в панику в описываемой ситуации, либо блокирование одного потока до завершения операции в другом.
Другое дело, что потоки могут независимо придти к выводу, что файл надо открыть и что-то с ним сделать, и у них будет два разных объекта File. И да, от этого rust не защитит. Но в этом случае, race происходит _вне_ rust'а. Здесь же речь идёт о _memory_ safety.
> А то что у вас, это просто переменная в памяти, которая в
> двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю,
> случайно где-нибудь наступить можно.Да, проходят в школе. И здесь я изложил самые-самые азы и то не полностью. О чём я кстати даже предупредил. Совершенно не удивительно, что тот единственный пример, который я привёл, оказался таким, который "проходят в школе". Или вы всё же полагаете, что мне следовало написать здесь целую книгу, сопроводив её десятком искусственных примеров, и несколькими десятками реальных, надёрганных из разных проектов на github'е?
Что-то по поделкам на пыхе статистика не лучше. Пожалуй, даже хуже. Эдак на пару порядков.
Хотя казалось бы - автоматическое управление памятью, GC, все дела.
> Что-то по поделкам на пыхе статистика не лучше. Пожалуй, даже хуже. Эдак
> на пару порядков.
> Хотя казалось бы - автоматическое управление памятью, GC, все дела.М... а с какой версии пых стал многопоточным?
Давай, расскажи нам, какие языки позволяют избежать гонки.
хаскель с STM
Как ни странно, Rust. Концепция владения и заимствования нацелена на разделение ресурсов и предотвращение гонок. Но если хочется, всегда есть unsafe.
Правильнее было бы сказать, что Rust позволяет предотвратить больше вариантов race condition, чем C. Но защитить от вобще всех вариантов race condition он само собой не может.
По идее он только от чего-то совсем тривиального сможет защитить - ценой довольно основательных неудобств для программиста. Стоит ли оно того - лет через пять-семь увидим...
Просто не нужно писать Си-код на Rust. Так-то программисты могут писать фортран-программы на любом языке программирования. Просто так делать не стоит.
yet another "просто не нужно писать код, если он не идеальный", только со своей колокольней, куликами и болотом, ага
Те, которые многопоточность толкмо не могут, конечно. В остальных - в крайнем случае для гонки понадобится ошибка в реализации среды. Чудес не бывает.
> Давай, расскажи нам, какие языки позволяют избежать гонки.Тот же D. Все "обычные" переменные локальны для потоков. Т.е. если ты объявишь "int a;" то в D это будет не глобальная переменная, которую может крутить каждый поток, конкурируя с соперниками. В D каждый поток получит свою копию этой переменной, которая будет храниться в TLS (thread-local storage). Если же тебе кровь из носу понадобится разделять её между потоками, то ты ее объявляешь разделяемой - "shared int a;". И компилятор теперь знает, что она разделяется между потоками и запретит тебе совершать над ней опасные, не синхронизированные, действия. Т.е. ты не сможешь тупо сделать "++a;", компилятор ругнется. Для этого тебе придется использовать специальные атомарные примитивы из модуля std.concurrency для исключения одновременного незащищенного доступа. И вообще, там (в D) для взаимодействия потоков побуждают использовать подсистему сообщений, максимально локализуя, обособляя потоки друг от друга. Взаимодействие через разделяемые данные (которые с квалификатором shared и конечно с помощью мьютексов и прочего из std.concurrency) оправданно только если объемы этих данных большие и копирование их в виде сообщений накладно.
> Енжой ёр Си.А что, есть ЯП где гонки невозможно сделать принципиально?
А не слили 32-битный в качестве демки?
(так вот о чём наши ядерщики на этой неделе говорили)
> В ядре Linux проблема была устранена 7 июля без информирования о влиянии исправления на безопасность.Не тому человеку дали Pwnie Awards, ой не тому.
Линус, помнится, вообще говорил, что уязвимости ничем от других ошибок не отличаются, и никаких специальных мер (отметки как уязвимости, приоритета при исправлении, уведомления вендоров и т.д.) нафиг не нужно. Исправлять только в порядке общей очереди.
Прям Доктор Манхеттен.
Как хорош все же canonical-livepatch.
uptime 343 days
А CVE-2017-7533 закрыт, как и все прочие.
Сколько бы виндовые хомячки лора и опеннета не визжали, а на реальных серверах Ubuntu прекрасна.
Сейчас бы в 2017 аптаймом меряться.P.S. Недавно без сожалений ребутнул серер точного времени с аптаймом > 5 лет.
Я в прицнипе не спорю, но аптайм - пофиг.Если доступность действительно важна - значит, есть резервирование и последовательная перезагрузка - не проблема. Если резервирования нет - значит, не надо, и перезагрузка тоже не проблема.
еще бывает банальное - "доступность важна, но денег на полноценный резерв нет и не будет, есть только аварийные системы".но вообще-то лучше систем с аптаймами в годы избегать - рано или поздно оно случайно перезагрузится (причем не во время тихое, а в самый неподходящий момент), и тут выяснится, что два года назад что-то руками поправили, но при перезагрузке оно слетает, или наоборот, что-то поменяли, в том числе стартовые скрипты, а оно с ошибкой и ключевой сервис вообще не запускается.
как ни старайся быть аккуратным - все равно что-нибудь упустишь. А поскольку с момента исправления прошли десятки месяцев - не так уже и просто выяснить, кто, чего и зачем там трогал.
и это не говоря уже о том, какие прелестные возможности live patch предоставляет для прятанья следов pwning.
Это называется "админ считает, что доступность важна, менеджер - что нет". Бывает, ну там там жизнь покажет, кто из них прав (кстати, менеджеры оказываются правы гораздо чаще, чем кажется админам с программистами).А вот насчёт забытых настроек и подобного - поддерживаю обеими руками. Причём ещё окажется, что владельца тайного знания год как нет. Примерно за это я люблю подход "что-то умерло - снести, врубить резерв" и прочие модные штуки вроде контейнеров, stateless-микросервисов и подобного - очень способствует переносу знаний из головы в конфигурацию.
> Это называется "админ считает, что доступность важна, менеджер - что нет".есть еще распространенный вариант - "вы же специалисты, сделайте нам бесплатно".
кто у нас там - банк разрытие вчерась навернулся, поскольку ниасилил резервную опту себе в датацентр (именно вот в момент, когда щисливые клиенты и без того обдумывают житье - то ли снять все вклады не взирая на штрафы, то ли снять все вклады и еще и текущий счет закрыть, и когда любой ценой надо изображать стабильность)?
(на самом деле еще и аван-гад туда же, но те быстро оклемались, часа два только ничего не работало)
Я вам просто напомню: http://www.opennet.me/opennews/art.shtml?num=36401
и где ссыль на exploit ?
Сказал же, что уязвимость локальная — вот и ищите на http://127.0.0.1/
Недоступно... http://hnng.moe/f/T9s
Судя по скриншоту, локализация тоже полетела, так что, похоже, проблемы глобальные. Советую перепрошить и потом попробовать снова.
> Судя по скриншоту, локализация тоже полетела, так что, похоже, проблемы глобальные. Советую перепрошить и потом попробовать снова.Вы не видели ua_UA.UTF-8 похоже.
>> Судя по скриншоту, локализация тоже полетела, так что, похоже, проблемы глобальные. Советую перепрошить и потом попробовать снова.
> Вы не видели ua_UA.UTF-8 похоже.Нет, это кое-кому отказало чувство юмора. Не говоря о том, что ru_RU.UTF-8 и en_US.UTF-8 будут выглядеть точно также в данном случае.
> Нет, это кое-кому отказало чувство юмора.А если чувства юмора у человека нет и не было?
> Не говоря о том, что ru_RU.UTF-8 и en_US.UTF-8 будут выглядеть точно также в данном случае.
Прошу прощения, но если вы генерируете страницу по локали то не обязательно будут использоваться две.
Типичный User@localhost.
вопрос был не об уязвимости а оссылке на exploit. чукча типа писатель..
а зачем тебе? комиттеры в апстрим ядро и мэйнтэйнеры дистрибутивов получили репродюсер, доказывающий что уязвимость есть и об который они тестировали фиксы. а остальным профанам зачем?хочешь эксплойт - пиши эксплойт, механизм гонки раскрыт, ничо там сложного нет, такой же рэйс как десяток других.
не умеешь в си и внутренние структуры ядра - сиди обтекай или покупай в даркнете.
>В ядре Linux проблема была устранена 7 июля без информирования о влиянии исправления на безопасность.крутой подход, мейнстримный, денежный
> В ядре Linux проблема была устранена 7 июля без информирования о влиянии исправления на безопасность.Пишите плиз корректно. Человек делал глобальный cleanup - и случайно зацепил и эту проблему, даже наверно не задумываясь о том что это такое.
> Пишите плиз корректно. Человек делал глобальный 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 до сих пор не открыли доступ.
> Уязвимость устранена в Ubuntu
> Проблема пока не решена в DebianДыра в системе? Пустяки, стабильность важнее.
>> Уязвимость устранена в Ubuntu
>> Проблема пока не решена в Debian
> Дыра в системе? Пустяки, стабильность важнее.у вас просто недостаточно стабильный дебиан - в позапрошлой версии ядро без этого бага.
ну а что дебиановцы не умели и не умеют самостоятельно поддерживать ядра, как бе и не новость ни разу. Двустрочные патчи бэкпортят неделями, а если, ненароком, там не все делается копипастой, то можно и пару месяцев подождать. Стабильность...
кого не устраивает - берет и сам себе ставит vanilla ядро поновее - тем более что родное-"стабильное" от vanilla обычно ничем полезным не отличается, это вам не rh с ее тремя сотнями патчей.
> тем более что родное-"стабильное" от vanilla обычно ничем полезным не отличается, это вам не rh с ее тремя сотнями патчей.действительно, это не rh с тремя сотнями патчей
на штатное ядро Debian 8 сейчас идут 730 патчей, на штатное ядро Debian 9 - 458
а не хотите 15к патчей у шапки ?
я говорю про *целых триста патчей* :)
ах простите. Это ваш оппонент туфту гонит. В 7.3 было ~16k патчей - включая цельнотянутый сетевой стек от ~4.8.
> а не хотите 15к патчей у шапки ?как и у дебиана, большую часть можно просто выкинуть без вреда для себя. Драйвера чего-нибудь, чего у тебя никогда не будет, или исправления чего-то вроде s360.
остальное либо бэкпорты (то есть vanilla как минимум не хуже), либо что-то совсем странное.все же, если их отбросить, останется около трех сотен, которые уже просто так не отбросишь - либо исправляют что-то, без чего вообще-то жить нехорошо, либо лезут в такие потроха системы, что нужно слишком много лишних знаний, чтобы оценить их нужность/ненужность.
В частности, пресловутый рут для n_tty.c был тихо исправлен за пару лет до общего шухера. Причем не так, как сейчас в vanilla, там больше покрыто локами.
А в дебиане как-то ни разу ничего ценного не попадалось, одни копипасты из lk. Я, правда, девятый не видел и не планирую заглядывать, но что-то сильно сомневаюсь, что там откуда-то взялся мега-девелопер.
> Драйвера чего-нибудь, чего у тебя никогда не будет, или исправления
> чего-то вроде s360.это у тебя s360x никогда не будет и, возможно, даже юзерского шелла в такую систему. а клиенты с такими системами заплатили денег (которых у тебя, возможно, тоже никогда не будет) за патчи, который им нужны и важны.
> а клиенты с такими системами заплатили денегну, необязательно, есть же "бесплатный" debian systemZ (это ж вроде 390 и есть) - и даже, видимо, кому-то из разработчиков шелл на ней даден. Чтоб денех никому не платить, ага ;-)
хотя я с большим трудом представляю себе контингент пользователей данной комбинации. (впрочем, вполне возможно, что это, + SLES и кто там есть еще - это одна и та же s390 - и что она вообще на свете осталась такая одна ;-)
с inotify нельзя указать каталог и получать события при изменении любого подкаталога и файла в любом подкаталоге и это плохо, приходится сканировать все каталоги и их слушать(((
> с inotify нельзя указать каталог и получать события при изменении любого подкаталога
> и файла в любом подкаталоге и это плохо, приходится сканировать все
> каталоги и их слушать(((вроде была фича наследования флагов и подъема события по каталогам вверх..
> с inotify нельзя указать каталог и получать события при изменении любого подкаталога
> и файла в любом подкаталоге и это плохоэто не плохо, это защита от идиотов(-разработчиков). представь, что кто-то вешает inotify на /
Почему вешать inotify на / это плохо?
> Почему вешать inotify на / это плохо?Вовсе не плохо. Продолжай перебегать улицу на красный свет и "вешать inotify на /" - тебе можно.
Почему перебегать улицу на красный свет плохо, мне объясняли. Почему вешать inotify на / плохо, мне не объясняли.
Учить дураков - тяжкий труд. Труд, согласно Конституции, должен быть оплачен. Тяжкий труд должен быть оплачен хорошо.
Выставляй своё предложение в Jobs, я думаю за тыщщу кто нить согласится, по е-мэйлу. (Я - нет)
> Почему перебегать улицу на красный свет плохо, мне объясняли.Для будущего асфальторовнятеля в модной оранжевой робе этого достаточно.
>В ядре Linux проблема была устранена 7 июля без информирования о влиянии исправления на безопасность.вот только ядра с этим коммитом вышли только вчера (4.12.5) и сегодня (4.9.41 4.4.80 ...)
> вот только ядра с этим коммитом вышли только вчера (4.12.5) и сегодня
> (4.9.41 4.4.80 ...)Так это для гентушников. Для остальных давно вышли...