The OpenNET Project / Index page

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



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

Оглавление

Уязвимость в OpenZFS, нарушающая обработку прав доступа во FreeBSD, opennews (??), 28-Авг-20, (0) [смотреть все]

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


17. "Уязвимость в OpenZFS, нарушающая обработку прав доступа во F..."  –2 +/
Сообщение от Lex (??), 28-Авг-20, 09:44 

> Наверное, если Lex умеет так делать (а не просто злорадствовать), его тут
> же наймет любая команда разработки ОС (любой ОС!) - золотое умение.

Конкретно с разработкой ОС я мало пересекаюсь, но даже мне отлично известно, что, при каких-либо ощутимых изменениях, вначале идет долгая фаза альфа/бета/итп тестирования, лишь по итогу которой правки отправляются в "прод".
Но никак в прод не валятся те изменения, при которых уже через считанные дни проступают эпические дыры.

> Ведь добавить ZFS в Windows, например, было бы круто (и есть даже
> проект), но там те же проблемы - неуверенность, что два куска
> кода будут идеально работать в любых условиях. А тут - БАЦ!
> - приходит Lex, умеющий читать код, и гарантирующий, что все будет
> работать без косяков, это же какой буст в интеграции кода разных
> команд будет!

ЗФС - странная штука. Вроде бы все о ней говорят, о том, какая она крутая, притом, уже несколько лет( за которые восторженные вопли о ней, кстати, начали утихать )..
но, начинаешь лезть в детали - и карета превращается в тыквы: то оказывается, что зфс кагбэ немало ресурсов системы жрет( ОЗУ, ЦП и проч ), то оказывается, что она не шибко то и отказоустойчива, да и горячая замена и проч работают не всегда и не везде, по крайней мере, сразу и запросто, то - еще что-то.
Крч., получается ситуация почти как GraphQL.

В случае с виндой - многих и NTFS вполне устраивает.


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

18. "Уязвимость в OpenZFS, нарушающая обработку прав доступа во F..."  +/
Сообщение от Аноним (18), 28-Авг-20, 10:12 
> Крч., получается ситуация почти как GraphQL.

А что не так с GraphQL?

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

26. "Уязвимость в OpenZFS, нарушающая обработку прав доступа во F..."  +2 +/
Сообщение от Lex (??), 28-Авг-20, 11:21 
>> Крч., получается ситуация почти как GraphQL.
> А что не так с GraphQL?

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

На первый взгляд смотрится интересно, но, как начинаешь разбираться...

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

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

В то же время пропагандирует слишком много свободы в плане обмена данными( на стороне клиента определяется какие конкретно данные оно хочет получить с бэка, какие конкретно поля должен содержать ответ и проч, хотя не без нюансов. При нескольких разных версиях клиента может возникнуть серьезнейший бардак в потоках данных ).
Это чем-т напоминает 5-10 летнее прошлое, когда разного рода NO-SQL БД отсутствие какой-либо схемы и возможность валить данные любой структуры в них изображали в качестве невероятного плюса.

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

Для себя в свое время принял как наиболее интересные и оптимальные - разные подобия JSON-RPC, поскольку нет привязки к способу обмена данными( HTTP кодами "сигналить" разные сообщения как некоторые любят, угу. Особенно, если потом требуется переезд на сокеты форменное веселье начинается ), клиент понятия не имеет о внутренней организации данных и прочего и ему в принципе не надо этого( т.к он просто отправляет на бэк название функции и ее аргументы и вполне логично ожидает получить ответ в известном диапазоне результатов ), один запрос может содержать в себе целую "пачку" RPC-запросов( массив объектов, в котором каждый объект - запрос, со своим именем, аргументами и проч ), а ответ - целую пачку ответов вместо кучи одиночных запросов и ответов.

Ну это по памяти, разбирался активно с этими штуками более года назад, так и не нашел в GraphQL чего-то реально интересного и однозначно перевешивающего все остальные решения и подходы. Штука интересная и.. и на этом все.
Почти как с блокчейном, который "классические" БД, как ни странно, так и не заменил, как бы его куда ни попадя не толкали бы годами напролет и вкидывали кучи денег.

На фоне нескончаемого фейсбучного бардака( у этих гениев постоянно то поддержка чего-то отваливается, то что-то где-то ломается в их SDK, API, какие-то апи и проч устаревают и проч ), складывается ощущение, что это просто подобие т.н техно-пиара( сегодня одно, завтра - другое. Главное - сохранить образ технологичности ), поскольку даже самим идейным разработчикам их "гениальные" подходы и решения не позволяют сделать реально отказоустойчивый продукт, с непрошибаемым API и SDK.
Зато, все тестами и типизациями обмазано. Правда, еще пару лет назад тупо не подключалось, поскольку гении SDK для яблока для разных кроссплатформенных штук ожидали увидеть в захардкоженной директории "/имя_пользователя/Documents/FacebookSDK" вне зависимости от местоположения проекта.
Хотя, подобным и гугл грешит - самая большая боль обычно возникает именно при интеграции продуктов от ФБ и Гугла.. хотя, вроде бы типо_мастера в ИТ, все такие протестированы да типизированные и весь остальной мир учат как код кодить.

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

36. "Уязвимость в OpenZFS, нарушающая обработку прав доступа во F..."  +/
Сообщение от анонн (ok), 28-Авг-20, 12:52 
>> Наверное, если Lex умеет так делать (а не просто злорадствовать), его тут
>> же наймет любая команда разработки ОС (любой ОС!) - золотое умение.
> Конкретно с разработкой ОС я мало пересекаюсь, но даже мне отлично известно,
> что, при каких-либо ощутимых изменениях, вначале идет долгая фаза альфа/бета/итп тестирования, лишь по итогу которой правки отправляются в "прод".
> Но никак в прод не валятся те изменения, при которых уже через считанные дни проступают эпические дыры.

Интересно, читать цитируемое местные оналитеки не пробовали?
>> "Кодовая база FreeBSD переведена на использование OpenZFS (ZFS on Linux)"
>> Реализация файловой системы ZFS в основной ветке FreeBSD (HEAD)

https://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd...

> FreeBSD-CURRENT is the very latest source code for FreeBSD and includes works in progress, experimental changes, and transitional mechanisms that might or might
>

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

104. "Уязвимость в OpenZFS, нарушающая обработку прав доступа во F..."  –1 +/
Сообщение от Ананимас008 (?), 29-Авг-20, 01:48 
зачем? Jlanchaтые сюда похихикать приходят, для них наверно будет отрытием, что 13 ветка еще не релизнулась и нужна лишь разработчикам.
Ответить | Правка | Наверх | Cообщить модератору

74. "Уязвимость в OpenZFS, нарушающая обработку прав доступа во F..."  +/
Сообщение от Аноним (-), 28-Авг-20, 15:51 
> оказывается, что зфс кагбэ немало ресурсов системы жрет( ОЗУ, ЦП и проч )

RAM жрёт так же, как жрал Solaris - даже немного меньше местами. Потому что кэширование (которое, кстати, можно настроить/ограничиь). А что, должно быть не так?

> то оказывается, что она не шибко то и отказоустойчива

В смысле? Что, у Вас пул с резервированием вылетел при крахе одного носителя? Да ну не может быть.

> да и горячая замена и проч работают не всегда и не везде, по крайней мере, сразу и запросто,

У меня и всех моих знакомых с самого раннего порта всё работает, сразу, запросто. Этому zpool'у что дашь - то и жрёт, если не дать слишком малый размер диска/раздела, конечно. И горячий резерв работает, и горячая замена, и даже горячая МИГРАЦИЯ. Годами. Так-то.

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

112. "Уязвимость в OpenZFS, нарушающая обработку прав доступа во F..."  +/
Сообщение от microsoft (?), 29-Авг-20, 21:01 
Молодчинка, теперь утри слюнки и спать. Не у всех на локалхосте тоже что и у тебя.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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