forum.opennet.ru

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

Оглавление

Локальная root-уязвимость в подсистеме inotify ядра Linux, opennews (??), 04-Авг-17, (0) [смотреть все]

Енжой ёр Си , Аноним (-), 23:02 , 04-Авг-17, (1) –22 //

Не все уязвимости сводятся к переполнению стека массива Гораздо больше логическ, Вареник (?), 23:07 , 04-Авг-17, (4) +17 //

На самом деле желание молодежи меньше работать и больше зарабатывать вполне поня, Аноним (-), 23:10 , 04-Авг-17, (6) +4 //

Офигенный идеал, зачем тогда погромист, платить ему 200 баксов за весь фигак-фиг, Онтон (?), 23:45 , 04-Авг-17, (12) +4

программисты против языков которые упрощают программирование, так как им платить, 564625145 (?), 08:02 , 05-Авг-17, (35) –1

Давайте, все настоящие программисты кодят только на асме и ниже , Анонс (?), 09:10 , 05-Авг-17, (40)
В мои времена программистам платили с доходов компании, и соответственно, чем бо, Старый одмин (?), 20:29 , 05-Авг-17, (65) +1

В мои времена им платили по 120 руб мес Белые халаты бесплатно , Аноним (-), 20:46 , 05-Авг-17, (66) +1

Это сразу после института Тогда верю, kerneliq (ok), 09:48 , 07-Авг-17, (81)

В СССР вообще ИТР-ы получали меньше работяг Глупость - но факт Не везде и не в, _ (??), 16:10 , 08-Авг-17, (87) +1

Написан непограммист Ты забыл третий ключевой пункт в сфере разработки ПО Поск, Аноним (-), 07:53 , 05-Авг-17, (34)

- Что это вы эту кривую двуногую табуретку везде с собою носите - Я её не ношу, , Аноним (-), 20:49 , 05-Авг-17, (67) +4

Это приводит к уменьшению заработка, Аноним (-), 10:53 , 07-Авг-17, (82) –1

А у них негров линчуют , да Здесь речь про race condition и переполнение буфер, Ordu (ok), 10:17 , 05-Авг-17, (41) +2 //

Смогли бы Если пришли к расту, предварительно изучив ассемблер и поработав го, Crazy Alex (ok), 12:24 , 05-Авг-17, (46) +2

Я не могу говорить определённо в силу отсутствия фактов -- раст действительно мо, Ordu (ok), 22:37 , 05-Авг-17, (70) +6

Тут верный способ рассуждений такой а кому ВЫГОДНО вкладываться в развитие Rust, pripolz (?), 17:20 , 11-Авг-17, (91) –1

Не совсем так Выгодно всем, кто хоть немного в теме Вопрос в том, кто вкладыва, Ordu (ok), 19:46 , 11-Авг-17, (92)

i чисто механически, следуя определённым правилам программирования, типа не ис, eganru (?), 15:05 , 05-Авг-17, (50)

Rust не позволить написать код, который одложит указатель в событие inotigy и од, pda (?), 16:03 , 05-Авг-17, (54) +1
Я сейчас потратил полчаса пытаясь изобрести краткое объяснение Мне не удалось э, Ordu (ok), 17:06 , 05-Авг-17, (55) +2

спасибо в общих чертах понял , egan_ru (?), 18:05 , 05-Авг-17, (60)
Это все простейшие примеры А логические гонки, когда, например первое что приш, Аноним (-), 12:33 , 15-Авг-17, (94) –1

При всём при этом, возникает вопрос, придется ли мучится, если реально логикой э, Аноним (-), 12:35 , 15-Авг-17, (95)

gt оверквотинг удален На такие случаи есть RefCell RefCell сам по себе immuta, Ordu (ok), 19:29 , 15-Авг-17, (97) +1

Чем эта гонка логическая Чтобы читать в или писать из File нужна mutable ссыл, Ordu (ok), 19:24 , 15-Авг-17, (96) +1

Что-то по поделкам на пыхе статистика не лучше Пожалуй, даже хуже Эдак на пару, Аноним (-), 23:07 , 04-Авг-17, (5) +8 //

М а с какой версии пых стал многопоточным , Аноним (-), 10:58 , 07-Авг-17, (83)

Давай, расскажи нам, какие языки позволяют избежать гонки , Аноним (-), 23:43 , 04-Авг-17, (11) //

хаскель с STM, анонимус (??), 00:15 , 05-Авг-17, (17) +2
Как ни странно, Rust Концепция владения и заимствования нацелена на разделение , irinat (ok), 00:54 , 05-Авг-17, (21) +5 //

Правильнее было бы сказать, что Rust позволяет предотвратить больше вариантов ra, angra (ok), 03:36 , 05-Авг-17, (26) +3

По идее он только от чего-то совсем тривиального сможет защитить - ценой довольн, Crazy Alex (ok), 15:33 , 05-Авг-17, (51)

Просто не нужно писать Си-код на Rust Так-то программисты могут писать фортран-, irinat (ok), 18:40 , 05-Авг-17, (61)

yet another просто не нужно писать код, если он не идеальный , только со своей , Аномномномнимус (?), 19:58 , 05-Авг-17, (64)

Те, которые многопоточность толкмо не могут, конечно В остальных - в крайнем сл, Crazy Alex (ok), 12:27 , 05-Авг-17, (48)
Тот же D Все обычные переменные локальны для потоков Т е если ты объявишь , Очередной аноним (?), 11:26 , 18-Авг-17, (98)

А что, есть ЯП где гонки невозможно сделать принципиально , Аноним (-), 18:48 , 13-Авг-17, (93) –1

А не слили 32-битный в качестве демки так вот о чём наши ядерщики на этой недел, Michael Shigorin (ok), 23:04 , 04-Авг-17, (2) –5
Не тому человеку дали Pwnie Awards, ой не тому , Аноним (-), 23:04 , 04-Авг-17, (3) //

Линус, помнится, вообще говорил, что уязвимости ничем от других ошибок не отлича, Аноним (-), 23:14 , 04-Авг-17, (7) +1 //

Прям Доктор Манхеттен , Аноним (-), 17:12 , 05-Авг-17, (56) –1

Как хорош все же canonical-livepatch uptime 343 daysА CVE-2017-7533 закрыт, как , Ergil (ok), 23:32 , 04-Авг-17, (9) +1 //

Сейчас бы в 2017 аптаймом меряться P S Недавно без сожалений ребутнул серер точ, Аноним (-), 00:05 , 05-Авг-17, (14) +3
Я в прицнипе не спорю, но аптайм - пофиг Если доступность действительно важна - , Crazy Alex (ok), 00:10 , 05-Авг-17, (16) +7 //

еще бывает банальное - доступность важна, но денег на полноценный резерв нет и , пох (?), 12:19 , 05-Авг-17, (45) +4 //

Это называется админ считает, что доступность важна, менеджер - что нет Бывае, Crazy Alex (ok), 15:39 , 05-Авг-17, (52)

есть еще распространенный вариант - вы же специалисты, сделайте нам бесплатно , пох (?), 13:07 , 06-Авг-17, (73) +1

Я вам просто напомню http www opennet ru opennews art shtml num 36401, asdsdsa (?), 01:50 , 05-Авг-17, (25)

и где ссыль на exploit , Sfinx (ok), 23:50 , 04-Авг-17, (13) –2 //

Сказал же, что уязвимость локальная 8212 вот и ищите на http 127 0 0 1 , Аноним (-), 00:35 , 05-Авг-17, (19) +12 //

Недоступно http hnng moe f T9s, Аноним (-), 00:49 , 05-Авг-17, (20) //

Судя по скриншоту, локализация тоже полетела, так что, похоже, проблемы глобальн, Аноним (-), 00:55 , 05-Авг-17, (22)

Вы не видели ua_UA UTF-8 похоже , Аноним (-), 00:56 , 05-Авг-17, (24) +2

Нет, это кое-кому отказало чувство юмора Не говоря о том, что ru_RU UTF-8 и en_, Аноним (-), 10:36 , 05-Авг-17, (42) –1

А если чувства юмора у человека нет и не было Прошу прощения, но если вы генерир, Аноним (-), 17:29 , 05-Авг-17, (59) +1

Типичный User localhost , Аноним (-), 00:55 , 05-Авг-17, (23) +1

вопрос был не об уязвимости а оссылке на exploit чукча типа писатель , Sfinx (ok), 13:20 , 05-Авг-17, (49) –2 //

а зачем тебе комиттеры в апстрим ядро и мэйнтэйнеры дистрибутивов получили репр, Мегазаычы (?), 15:49 , 06-Авг-17, (75) +1

крутой подход, мейнстримный, денежный, Аноним (-), 00:26 , 05-Авг-17, (18) +1
Пишите плиз корректно Человек делал глобальный cleanup - и случайно зацепил и э, Аноним (-), 08:12 , 05-Авг-17, (36) //

Ничего подобного, в багтрекере Red Hat сведения об уязвимости появились 6 июля, , Аноним (-), 08:29 , 05-Авг-17, (38) +2

Дыра в системе Пустяки, стабильность важнее , Аноним (-), 09:02 , 05-Авг-17, (39) –1 //

у вас просто недостаточно стабильный дебиан - в позапрошлой версии ядро без этог, пох (?), 12:24 , 05-Авг-17, (47) –4 //

действительно, это не rh с тремя сотнями патчейна штатное ядро Debian 8 сейчас и, бедный буратино (ok), 17:22 , 05-Авг-17, (58) //

а не хотите 15к патчей у шапки , Аноним (-), 20:53 , 05-Авг-17, (68) –1

я говорю про целых триста патчей , бедный буратино (ok), 21:15 , 05-Авг-17, (69)

ах простите Это ваш оппонент туфту гонит В 7 3 было 16k патчей - включая цель, Аноним (-), 09:16 , 06-Авг-17, (71)

как и у дебиана, большую часть можно просто выкинуть без вреда для себя Драйвер, пох (?), 13:25 , 06-Авг-17, (74) –1

это у тебя s360x никогда не будет и, возможно, даже юзерского шелла в такую сист, Мегазаычы (?), 15:54 , 06-Авг-17, (76)

ну, необязательно, есть же бесплатный debian systemZ это ж вроде 390 и есть , пох (?), 22:15 , 06-Авг-17, (78) –1

с inotify нельзя указать каталог и получать события при изменении любого подката, anonymous (??), 18:46 , 05-Авг-17, (63) –1 //

вроде была фича наследования флагов и подъема события по каталогам вверх , Аноним (-), 09:16 , 06-Авг-17, (72)
это не плохо, это защита от идиотов -разработчиков представь, что кто-то вешае, Мегазаычы (?), 15:56 , 06-Авг-17, (77) +1 //

Почему вешать inotify на это плохо , Аноним (-), 23:29 , 06-Авг-17, (79) –2 //

Вовсе не плохо Продолжай перебегать улицу на красный свет и вешать inotify на , Led (ok), 01:47 , 07-Авг-17, (80) +2

Почему перебегать улицу на красный свет плохо, мне объясняли Почему вешать inot, Аноним (-), 11:20 , 07-Авг-17, (84)

Учить дураков - тяжкий труд Труд, согласно Конституции, должен быть оплачен Тя, _ (??), 16:51 , 08-Авг-17, (88)
Для будущего асфальторовнятеля в модной оранжевой робе этого достаточно , Led (ok), 21:31 , 08-Авг-17, (89)

вот только ядра с этим коммитом вышли только вчера 4 12 5 и сегодня 4 9 41 4 , Sylvia (ok), 12:15 , 07-Авг-17, (85) –2 //

Так это для гентушников Для остальных давно вышли , Led (ok), 23:21 , 07-Авг-17, (86)

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

41. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +2 +/–

Сообщение от Ordu (ok), 05-Авг-17, 10:17

> Гораздо больше логических ошибок,
"А у них негров линчуют", да? Здесь речь про race condition и переполнение буфера, то есть про ошибки которых можно избегать чисто механически, следуя определённым правилам программирования, типа "не использовать unsafe".
> только создадут излишние надежды у молодежи
Меня вот до сих пор удивляет то, с какой настырностью люди лезут в абсолютно неквалифицированные воспитатели, причём полагая себя умнее воспитуемых. Почему ты полагаешь, что подрастающие поколения настолько тупые, что они не смогут исследовать те ошибки, которые они совершают при написании кода на rust'е и не испытывать бесплодных надежд? То есть вот Вареник может даже не заглядывая в rust осознать, что rust не панацея, а вот подрастающие поколения такие тупые, что понять этого не смогут даже изучая rust, и даже реальное совершение ошибок их ничему не научит. Ну да, поколение ЕГЭ, я знаю. Все умные люди уже родились, Вареник был последним.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

46. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +2 +/–

Сообщение от Crazy Alex (ok), 05-Авг-17, 12:24

Смогли бы... Если пришли к расту, предварительно изучив ассемблер и поработав год-другой на си (и потыкавшись в несколько прежних "серебряных пуль"). Но они ж напрямую норовят лезть, и те вещи, который для сишника очевидны, относят к магии компилятора. Ровно так же нормальный вменяемый джавист, начинавший с более низкого уровня, отлично знает, что именно ему может в джаве прилететь, а тот, который кроме VM ничегоне нюхал - два слова не свяжет о том, какие у той же сборки мусора будут нюансы просто в силу архитектуры.
Раст ещё молод, чтобы это было с ним на практике видно, но у нас уже есть PHP, Python, Javascript и Java - там очень наглядно, что используемый язык на количество ошибок влияет очень слабо.
А что молодое поколение попустит, когда оно перестанет быть молодым - это называется опыт.

Ответить | Правка | Наверх | Cообщить модератору

70. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +6 +/–

Сообщение от Ordu (ok), 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/

Ответить | Правка | Наверх | Cообщить модератору

91. "Локальная root-уязвимость в подсистеме inotify ядра Linux" –1 +/–

Сообщение от pripolz (?), 11-Авг-17, 17:20

> считать что индукция в данном случае -- неверный способ рассуждений
Тут верный способ рассуждений такой: а кому ВЫГОДНО вкладываться в развитие Rust/Go/D ?
Приведу пример: MS Visual Studio принципиально не поддерживает стандарт C11 до сих пор.

Ответить | Правка | Наверх | Cообщить модератору

92. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +/–

Сообщение от Ordu (ok), 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 устаревшим и выкатит совершенно новый стек технологий, и скажет, что это самая распоследняя и наисовременнейшая технология, которой нет аналогов в мировом производстве.

Ответить | Правка | Наверх | Cообщить модератору

50. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +/–

Сообщение от eganru (?), 05-Авг-17, 15:05

[i]чисто механически, следуя определённым правилам программирования, типа "не использовать unsafe"[/i] - не могу осознать, каким образом unsafe связан c состоянием гонки в данном случае?
я не знаю rust и интересно, каким образом он помогает избегать состояний гонки.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

54. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +1 +/–

Сообщение от pda (?), 05-Авг-17, 16:03

Rust не позволить написать код, который одложит указатель в событие inotigy и одновременно даст другому куску кода владеть им с правом на запись.

Ответить | Правка | Наверх | Cообщить модератору

55. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +2 +/–

Сообщение от Ordu (ok), 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 (?), 05-Авг-17, 18:05

спасибо. в общих чертах понял.

Ответить | Правка | Наверх | Cообщить модератору

94. "Локальная root-уязвимость в подсистеме inotify ядра Linux" –1 +/–

Сообщение от Аноним (-), 15-Авг-17, 12:33

Это все простейшие примеры. А логические гонки, когда, например (первое что пришло, сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, а второй поток начинает читать от туда, но первый ещё не досохранял. Такое вот rust никак не отследит.
А то что у вас, это просто переменная в памяти, которая в двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, случайно где-нибудь наступить можно.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

95. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +/–

Сообщение от Аноним (-), 15-Авг-17, 12:35

> Это все простейшие примеры. А логические гонки, когда, например (первое что пришло,
> сильно надуманно, но думаю степень можно опять), мы сохраняем на диск,
> а второй поток начинает читать от туда, но первый ещё не
> досохранял. Такое вот rust никак не отследит.
> А то что у вас, это просто переменная в памяти, которая в
> двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю,
> случайно где-нибудь наступить можно.
При всём при этом, возникает вопрос, придется ли мучится, если реально логикой эти потоки разделены, то есть одновременное выполнение кода не возможно, потому что второй поток уснул в ожидание. Я так понял, rust за такое будет пинать

Ответить | Правка | Наверх | Cообщить модератору

97. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +1 +/–

Сообщение от Ordu (ok), 15-Авг-17, 19:29

>[оверквотинг удален]
>> сильно надуманно, но думаю степень можно опять), мы сохраняем на диск,
>> а второй поток начинает читать от туда, но первый ещё не
>> досохранял. Такое вот rust никак не отследит.
>> А то что у вас, это просто переменная в памяти, которая в
>> двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю,
>> случайно где-нибудь наступить можно.
> При всём при этом, возникает вопрос, придется ли мучится, если реально логикой
> эти потоки разделены, то есть одновременное выполнение кода не возможно, потому
> что второй поток уснул в ожидание. Я так понял, rust за
> такое будет пинать
На такие случаи есть RefCell. RefCell сам по себе immutable объект (а значит можно одновременно иметь много ссылок на него), но если его попросить, то он выдаст mutable ссылку на содержащийся в нём объект. При этом он выполнит в рантайме проверки того, что в любой момент времени существует только одна mutable ссылка на объект. По сути, этот RefCell -- это те же проверки, которые выполняет компилятор, отличие в том, что они выполняются в рантайме, а не во время компиляции. Если логические допущения о том, что одновременное выполнение кода невозможно, окажутся неверными, то поток вывалится в панику.

Ответить | Правка | Наверх | Cообщить модератору

96. "Локальная root-уязвимость в подсистеме inotify ядра Linux" +1 +/–

Сообщение от Ordu (ok), 15-Авг-17, 19:24

> Это все простейшие примеры. А логические гонки, когда, например (первое что пришло,
> сильно надуманно, но думаю степень можно опять), мы сохраняем на диск,
> а второй поток начинает читать от туда, но первый ещё не
> досохранял. Такое вот rust никак не отследит.
Чем эта гонка "логическая"? Чтобы читать в или писать из File нужна mutable ссылка на этот File. Но rust запрещает иметь две mutable ссылки. В зависимости от того, каким образом вы попытаетесь создать две такие ссылки в разных потоках, вы получите либо ошибку компиляции, либо падение одного из потока в панику в описываемой ситуации, либо блокирование одного потока до завершения операции в другом.
Другое дело, что потоки могут независимо придти к выводу, что файл надо открыть и что-то с ним сделать, и у них будет два разных объекта File. И да, от этого rust не защитит. Но в этом случае, race происходит _вне_ rust'а. Здесь же речь идёт о _memory_ safety.
> А то что у вас, это просто переменная в памяти, которая в
> двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю,
> случайно где-нибудь наступить можно.
Да, проходят в школе. И здесь я изложил самые-самые азы и то не полностью. О чём я кстати даже предупредил. Совершенно не удивительно, что тот единственный пример, который я привёл, оказался таким, который "проходят в школе". Или вы всё же полагаете, что мне следовало написать здесь целую книгу, сопроводив её десятком искусственных примеров, и несколькими десятками реальных, надёрганных из разных проектов на github'е?

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


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


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


	70. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+6 +/–
	Сообщение от Ordu (ok), 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/
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	92. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+/–
	Сообщение от Ordu (ok), 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 устаревшим и выкатит совершенно новый стек технологий, и скажет, что это самая распоследняя и наисовременнейшая технология, которой нет аналогов в мировом производстве.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


	55. "Локальная root-уязвимость в подсистеме inotify ядра Linux"	+2 +/–
	Сообщение от Ordu (ok), 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 = 2b. Допустим, я напишу функцию: 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 (?), 05-Авг-17, 18:05
	спасибо. в общих чертах понял.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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