The OpenNET Project / Index page

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



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

Оглавление

Уязвимости в драйвере NTFS-3G, позволяющие получить root-доступ в системе, opennews (ok), 26-Май-22, (0) [смотреть все]

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


47. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +2 +/
Сообщение от Аноним (36), 26-Май-22, 17:30 
Давай теперь я расскажу, как оно на самом деле.

Нативная ntfs венды, емнип, примерно на одном уровне с ext4 по производительности, что, при такой сложности и количестве впихнутых фич, весьма хорошее достижение. Сама ФС, конечно, потому что IO венды легко сасает. Только, вот, фрагментация, и рассыпается что-то подозрительно регулярно для продукта такого уровня.

Ntfs3g, которая через fuse, на 1-2 порядка (если не больше), в зависимости от задач, естественно, хуже, в сравнении с шифрованной ext4 через кучу прослоек, так ещё и весь процессор выжрет. О том, как всё нагреется в процессе, несмотря на черепашьи скорости, можно не говорить. Фрагментация, вот это вот всё, очень актуально для венды.

Ну и по возможностям ntfs3g обеспечивает наверно 1/10 от того, что применяется на практике последние лет 15, о низкой надёжности вообще нет смысла упоминать, она будет рассыпаться постоянно.

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

51. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  –1 +/
Сообщение от Аноним (41), 26-Май-22, 17:44 
> рассыпается что-то подозрительно регулярно для продукта такого уровня

У меня рассыпалась только один раз, и было это из-за перебитого ATA-кабеля, а тут уж никакая ФС не спасёт.

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

56. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (36), 26-Май-22, 17:56 
Да не, то, что активно добивает остатки при аппаратных ошибках, это отдельная тема. А вот когда при включённых сжатии/шифровании кончилось место и её разнесло на куски, вот это эпик уже, для 2017 года так точно. В очередной раз исправили, угумс.
Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Брат Анон (ok), 26-Май-22, 18:40 
> а тут уж никакая ФС не спасёт.

Есть очень простая схема -- две РАЗНЫХ контрольных суммы на каждый блок. И проверка контрольных сумм после записи блока. Просадка по скорости -- да, но кому надо -- тот давно решил все эти проблемы.

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

71. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (70), 26-Май-22, 19:27 
Есть простая схема, называется RAID. Но речь немного не об этом.
Ответить | Правка | Наверх | Cообщить модератору

109. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (109), 28-Май-22, 12:25 
RAID в чистом виде штука так себе. Ну вот смотри: есть RAID1, у нас две копии. Если винч совсем сдох - все просто, понятно где корректный вариант брать.

А если никто не сдох но 2 чтения 2 копий дали разный результат? Все ок, но кто из двух нам врет? Классический райд не дает ответ на этот вопрос. Поэтому провтивостоит сферическим факапам в вакууме. А хрень типа плохого кабла для него смерти подобна! :)

В этом месте мы начнем догадываться что юзерам zfs/btrfs/etc нравится в чексумах. Кроме всего прочего оно словив CSUM ERROR утащит вторую копию и из нее починит сбойную. А критерием ошибка чексума блока, вот так уже становится понятнее кто из девайсов/контроллеров/кабелей гонит.

NTFS в таких случаях чинится обычно до состояния "не монтируется - и хрен с ним, форматцэ!"

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

76. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +1 +/
Сообщение от RM (ok), 26-Май-22, 21:50 
>> а тут уж никакая ФС не спасёт.
> Есть очень простая схема -- две РАЗНЫХ контрольных суммы на каждый блок.
> И проверка контрольных сумм после записи блока. Просадка по скорости --
> да, но кому надо -- тот давно решил все эти проблемы.

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

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

110. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (109), 28-Май-22, 12:27 
Btrfs и zfs умеют юзать криптографические хэши в этом качестве. Это конечно медленнее, но если вы так легко на коллизии нарываетесь, откройте сервис по кряку паролей!
Ответить | Правка | Наверх | Cообщить модератору

116. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (-), 28-Май-22, 13:00 
> У меня рассыпалась только один раз, и было это из-за перебитого ATA-кабеля,
> а тут уж никакая ФС не спасёт.

Btrfs и zfs будут на раз орать про ошибки чексум. Очень даже спасет, так то.

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

52. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  –2 +/
Сообщение от пох. (?), 26-Май-22, 17:45 
Зачем ты тут рассказываешь сказочки для самых маленьких?

Любому же, кроме детсадовца, очевидно что все твои фантазии - из пальца высосаны.
А вот реальные мегабайтики в секунду - у меня в компактном окошечке браузера, рядышком (так уж получилось, что в совершенно одинаковых коробках под совершенно равномерной нагрузочой оказались)

И загрузка cpu, кстати, тоже. И опять влажные фантазии местных фанатов-фантазеров про "порядки" разбиваются о грубую реальность.

> Ну и по возможностям ntfs3g обеспечивает наверно 1/10 от того, что применяется на практике
> последние лет 15, о низкой надёжности вообще нет смысла упоминать, она будет рассыпаться
> постоянно.

бредни впопеннетчиков, рулоны на вес

Даааа, с таким норотцем импортозамещение уж построят так построят...

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

57. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (36), 26-Май-22, 18:03 
Никаких сказочек, у меня был диск с ntfs для чтения и рядом точно такой же диск с ext4 для записи. Я испытал много, много боли в процессе. Проблема была точно не с диском, потому что весьма эффективно перед этим с него был снят дамп. Я в полной пере насладился всеми прелестями переноса терабайт данных из неэффективного хранилища (а торренты через ntfs3g прелесть ещё та).
Ответить | Правка | Наверх | Cообщить модератору

105. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от InuYasha (??), 28-Май-22, 10:41 
I know that feel, bro.
У меня тоже половина шареных данных на нтфс. И торренты. :(
Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Брат Анон (ok), 26-Май-22, 18:41 
Пруфов, разумеется, как всегда не будет
#яснопонятно #расходимся #каквсегда
Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

77. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  –2 +/
Сообщение от пох. (?), 26-Май-22, 22:11 
Какие тебе "пруфы", д-л, если ты живешь в собственном маня-мирке?

Кому нужна ntfs - просто пользуется. Попутно иногда получая удивительные цифирки на градуснике.
Остальные с детсадовским уровнем мозга - просто фантазируют. "У них есть диск!" (разумеется, обиженка нажаловалась воспитателю и ответ удален)

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

111. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (-), 28-Май-22, 12:29 
А ты попробуй на нтфс ворочать иерархией размером с сорцы линукскернела хотя-бы - как раз и ощутишь что из себя нтфс представляет. А то что доступ к кэшу в раме быстрый никто и не сомневался, только это не заслуга ФС :)
Ответить | Правка | Наверх | Cообщить модератору

120. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +1 +/
Сообщение от пох. (?), 28-Май-22, 16:35 
> А ты попробуй на нтфс ворочать иерархией размером с сорцы линукскернела

А ЗАЧЕМ мне эта ненужная херня?

Собственно, у меня на рабочем месте "иерархия" около второй сотни терабайт уже отросла, но там порн...в смысле jpegи с pdf'ами. Ничего, живем. Причем это не ненужная херня, и ее еще архивировать/бэкапать приходится постоянно.

> доступ к кэшу в раме

кто о чем, а л@п4тый опять беседует с голосами в голове.

То на чем я с xfs сравнивал - бэкап сервера индексировался. Терабайтный. linear read (должен бы был быть, если бы верхние уровни не были тоже херней) Какой, найух, кэш в какой твоей раме?

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

125. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (-), 29-Май-22, 00:56 
> А ЗАЧЕМ мне эта ненужная херня?

Ну, блин, действительно зачем файлухе файлы хранить. Мне вон объяснили что важнее чтобы в именах файлов можно было войну и мир хранвить. Видимо у меня с маздайцами сильно разные приоритеты.

> Собственно, у меня на рабочем месте "иерархия" около второй сотни терабайт уже
> отросла, но там порн...в смысле jpegи с pdf'ами. Ничего, живем. Причем
> это не ненужная херня, и ее еще архивировать/бэкапать приходится постоянно.

Мне мягко говоря не вштыривает скорость работы NTFS. Особенно на холодную. А тратить мое время на туповэйтинг машинных операций мне как-то западло. Люблю user experience. И для меня это когда в компьютерных системах все происходит быстро и четко, так как задумано мной. NTFS страшно далек от этого.

> кто о чем, а л@п4тый опять беседует с голосами в голове.

NTFS на холодную без прогретого кеша - дичайший тормоз. Какие голоса, о чем ты? И чтобы это ощутить достаточно лишь поюзать линуха как свой десктоп, поворочать в нем проекты, а потом понять что на маздайный уровень перфоманса я более не согласен. И никакой WSL ему операции файлухи его гомнокернелом не разгонит.

> То на чем я с xfs сравнивал - бэкап сервера индексировался. Терабайтный.
> linear read (должен бы был быть, если бы верхние уровни не
> были тоже херней) Какой, найух, кэш в какой твоей раме?

Для меня индекс терабайтного бэкапа явно не является типовой злободневной задачей которая вот именно меня парит.

Но если мы о птичках, я cp --reflink за секунду делаю "копию" образа 2-терабайтного винча, и работаю уже с ней. И если профакаплюсь, спишу ту "копию" в утиль да новую рефлинкну. Она создается за секунду и места жрет только на дельту, как то цать блоков. Покажи мне такой фокус в маздайке вообще? Оно так умеет вообще? А то вот это делает меня сильно эффективнее на терабайтном файле, из которых у меня так то в основном readout с полутрупиков винчей характерным софтом, для целей датарекавери. А за сколько там бэкап индексируется мне честно гря похрен - я же не буду туповэйтить это лично.

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

135. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +2 +/
Сообщение от пох. (?), 29-Май-22, 11:39 
>> А ЗАЧЕМ мне эта ненужная херня?
> Ну, блин, действительно зачем файлухе файлы хранить. Мне вон объяснили что важнее

мне неинтересно твое линухксь кернел, а то что я храню - вот, вдвое быстрее xfs на идеально чистом тесте оказалось. Не то чтоб было надо, но результат несколько удивил. А учитывая размеры - в общем то да, надо бы подумать о переходе целиком на ntfs.

> чтобы в именах файлов можно было войну и мир хранвить. Видимо
> у меня с маздайцами сильно разные приоритеты.

да, ты херней страдаешь, а мы - просто используем. Поэтому нам наплевать на твой линyпсь, помойку из миллиарда мелких файлов, но не наплевать что банальное имя файла ограничено лимитами пятидесятилетней давности когда компьютеры были большие а кодировка acscii7, и просто скопировать его мы не можем.

> Мне мягко говоря не вштыривает скорость работы NTFS. Особенно на холодную. А

мне тебе сколько раз повторить что на моем очень убедительном для меня (поскольку идеально одинаковые коробки под совершенно одинаковой нагрузкой) кейсе оказалось что xfs невштыривает вдвое медленее?

> user experience. И для меня это когда в компьютерных системах все
> происходит быстро и четко, так как задумано мной. NTFS страшно далек

да не звизди ты про задумано. Жрать с лопаты что подали твое "задумано".

Ты ж пользуешься fs с 64x write amplification. И задумывал ее совсем не ты.

> NTFS на холодную без прогретого кеша - дичайший тормоз. Какие голоса, о

сказочник.

> Для меня индекс терабайтного бэкапа явно не является типовой злободневной задачей которая
> вот именно меня парит.

а меня именно она парит, потому что делается долго. А если бы мне был не нужен результат, что его можно и не ждать - зачем бы я его делать стал?
А твой линyпсь мне даром не сдался.

> Но если мы о птичках, я cp --reflink за секунду делаю "копию"
> образа 2-терабайтного винча, и работаю уже с ней. И если профакаплюсь,

и зачем мне твои страдания?
Я не занимаюсь "ремонт компьютеров, установка виндовс, выезд мастера, живу недалеко, приеду быстро".
Кстати, да, vss снапшоты недоступны л@п4тым ведь ни в ntfs3g, ни в парагоновской?

Или есть плагин но за денежку и бинарный под единственноверную платформу, как всегда?

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

146. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (-), 30-Май-22, 19:11 
> мне неинтересно твое линухксь кернел,

Зато мне интересен.

> а то что я храню - вот, вдвое быстрее xfs на идеально чистом тесте оказалось.

Я честно говоря не понимаю что такого хорошего в XFS вообще и зачем в него так вцепился редгад. По метаданным он тормоз. Был, есть и наверное будет.

> Не то чтоб было надо, но результат несколько удивил. А учитывая размеры - в
> общем то да, надо бы подумать о переходе целиком на ntfs.

Я даже не заморачивался особо бенчами XFS, ибо отделался от томов в нем эн лет назад. А если у редгада девелы остальных ФС уволились - это таки проблемы редгада, делать из этого свои проблемы я не собираюсь! Независимо от того какой там кактус сейчас в моде по версии их яхтсменов из отдела маркетинга, сами пусть свое жрут.

> да, ты херней страдаешь, а мы - просто используем.

Я тоже - просто использую. Может быть несколько иначе.

> Поэтому нам наплевать на твой линyпсь, помойку из миллиарда мелких файлов, но не наплевать
> что банальное имя файла ограничено лимитами пятидесятилетней давности когда компьютеры
> были большие а кодировка acscii7, и просто скопировать его мы не можем.

Ты в каждой новости "два дня за линуксом гонялась чтобы сказать как он безразличен" :))

> мне тебе сколько раз повторить что на моем очень убедительном для меня
> (поскольку идеально одинаковые коробки под совершенно одинаковой нагрузкой) кейсе
> оказалось что xfs невштыривает вдвое медленее?

Я в XFS вообще не особый эксперт. Если меня колебет только скорость я EXT4 юзаю, а если еще продвинутости и чексуммы то btrfs.

> да не звизди ты про задумано. Жрать с лопаты что подали твое "задумано".

Это имхо про винду. А в линуксе так то выбор фс поболее виндов...

> Ты ж пользуешься fs с 64x write amplification. И задумывал ее совсем не ты.

Да ты упрлс. Не получается у меня в моих кейсах такой фактор амплификации, хоть тресни.

> сказочник.

Видел я эти сказочки - колом на эн минут при заходе в диру. В лине на такой махровый позор нарваться - ну даже не знаю, не попадалось. Если тебе нравится так с операционкой работать тебе и карты в руки. Меня такой перфоманс не устраивает.

Бжад, даже одна и та же прога одним и тем же тулчейном в лине раза в 2.5 быстрее билдится. Это для меня таки мощный аргумент за то у кого system internals прогнили...

> а меня именно она парит, потому что делается долго. А если бы
> мне был не нужен результат, что его можно и не ждать - зачем бы я его делать стал?

А я знаю зачем тебе фтыкать на индексирование терабайта здесь и сейчас? Впрочем ты любишь в пятки стрелять. Самое интересное что почему-то себе. Мазохизм забавный но непрактичный.

> А твой линyпсь мне даром не сдался.

А я люблю принцип IBM: машина должна работать а человек думать. С линем мои машины работают явно лучше.

> и зачем мне твои страдания?

Тебе - ух не знаю.

> Я не занимаюсь "ремонт компьютеров, установка виндовс, выезд мастера, живу недалеко,
> приеду быстро".

Гггг попробуй такому вообще дать порушеный винч с хотя-бы EXT'ом, сможешь поржать с его табла.

> Кстати, да, vss снапшоты недоступны л@п4тым ведь ни в ntfs3g, ни в парагоновской?

А черт их знает, если честно. Кому оно надо тот пусть и проверяет.

> Или есть плагин но за денежку и бинарный под единственноверную платформу, как всегда?

Если честно - без понятия. У себя я тома NTFS выпилил много лет назад, а с юзеровских томов мне были нужны как максимум данные, которые уж точно не там.

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

139. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (-), 29-Май-22, 14:07 
> я cp --reflink за секунду делаю "копию" образа 2-терабайтного винча, и работаю уже с ней. И если профакаплюсь, спишу ту "копию" в утиль да новую рефлинкну.

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

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

141. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от пох. (?), 29-Май-22, 18:53 
Ну справедливости ради - когда он дохнет с реальной копией, сильно лучше от этого не становится, правда, шансов прочитать после mhdd хотя бы одну все же больше.

Собственно, ntfs я в том сетапе притащил именно в плане "чтоб иметь потом нормальные средства для восстановления, если уж совсем все пойдет плохо".

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

147. "Уязвимости в драйвере NTFS-3G, позволяющие получить root-дос..."  +/
Сообщение от Аноним (-), 30-Май-22, 19:27 
> А потом винт дохнет вместе со всеми двухсекундными копиями и становится реально забавно.

Ты не понял чувак, эти копии - с уже вычитаного образа, на _исправном_ стораже, читать образ на порушеный это номер! Изначально вычитывается, ессно, по рекомендациям лучших собаководов. Как то сперва coarse, с быстрым пропуском проблемных регионов. А потом уже долбим до победного насколько время и желание позволяет. В большинстве случаев образ у меня получается почти идеальный, плюс-минус десяток-другой особо строптивых бэдов.

А вот дальше... дальше есть у меня образ на пару терабайт. Что с ним делать? Пустить fsck да посмотреть - не смонтируется ли оно в стиле дешево и сердито. Но вот портить отчитаный с такими тантрумами образ - паскудство. А вдруг fsck его уроет? А тут то и лайфхак с пуском fsck на рефлинкнутой "копии". Делается за секунду, реально занимает места только на дельту относительно базы, а unshare прозрачно, в фоне делает ФС. И если результат не понравился, я просто снесу эту "копию", сделаю новую еще за секунду и попробую иначе. Места при этом оно жрет почти как один образ - но ведет себя как будто образов два. Это такой очень умный deduplicate когда я на фазе копирования сразу явно декларю что изначально копия - точный клон, но потом может и разъехаться, так что для софта это 2 независимых файла, типа.

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

Ггг а под линух так то тоже софт такого плана есть. Что через апи что через командочки. Есть такая штука, whdd например. Мне правда его стратегия блочного чтения не очень нравится, зато он умеет через команды пулять, как mhdd. Только сразу из линуха, что удобнее досявого уродца.

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

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

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

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




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

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