Тео де Раадт придумал, как сделать openat() реально безопасным, потому что оказалось, что он таким не был

Jказывается, замена open() на openat() сама по себе ничего не дает с точки зрения безопасности. Если передать в openat() абсолютный путь вроде "/etc/hosts", функция просто проигнорирует переданный dirfd и откроет файл как обычно, полностью игнорируя попытку "привязать" доступ к конкретному каталогу. То есть вся эта конструкция с openat(), которую многие программисты годами считали защитным механизмом от directory traversal, на деле защищает ровно ни от чего, если разработчик явно не добавил проверки сам.

Де Раадт уперся в эту проблему практически — при разработке openrsync понадобилось жестко ограничить программу от выхода за пределы рабочего каталога, а стандартные unveil() и pledge() для этой задачи не годились. Предложение получилось элегантным: флаг F_BELOW для fcntl() (или O_BELOW для open()), который делает ограничение частью самого файлового дескриптора, а не ответственностью программиста на каждый вызов. Если dirfd помечен таким флагом, любая попытка уйти через ".." или абсолютный путь просто упадет с ENOENT. Разница принципиальная - вместо того, чтобы полагаться на внимательность разработчика, который должен не забыть проверку на каждом из десятков мест в коде, ограничение зашивается прямо в дескриптор на уровне ядра.

Отдельно порадовал пассаж про Linux-аналоги RESOLVE_BENEATH и RESOLVE_IN_ROOT для openat2 — де Раадт прямым текстом указал, что эти флаги страдают той же проблемой: их нужно добавлять вручную ко всем нужным вызовам, а в случае захвата процесса атакующий всегда найдет другой способ открыть файл в обход этих проверок.

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

Linux / Линукс🥸

4 октября 1999 года официально был основан Gentoo , тогда же был запущен официальный сайт.

Linux / Линукс🥸

Инженер из NVIDIA протестировал уровень задержек при использовании Wayland и X.Org

Камиль Лысик, работающий в компании NVIDIA, выступил на конференции XDC 2026 с докладом, в котором рассказал о результатах тестирования задержек вывода информации в окружениях GNOME 49.7 (mutter) и KDE 6.7.4 (kwin) при использовании X.Org Server и Wayland. Задействованный в исследовании код опубликован под лицензией MIT.
В целом выводы сводятся к тому, что различия в отзывчивости не существенны и трудно выделить одного победителя. Наибольшее влияние на задержки, по мнению Камиля, вносят обработка ввода и организация вывода на монитор. Отдельно отмечена технология адаптивного изменения частоты обновления экрана (VRR), включение которой позволило заметно повысить отзывчивость. Также упомянуто решение проблем с задержками, в прошлых тестированиях возникавших при использовании XWayland - в новой кодовой базе XWayland появление дополнительных задержек не зафиксировано.

Предложенный метод оценки отзывчивости интерфейса близок к исследованию, проведённому в июле Марком Неттом. Как и в прошлом исследовании для точного измерения времени от нажатия клавиши до изменения информации на экране использовалось специальное аппаратное устройство на базе микроконтроллера ЕSP32-S3, к которому был подключён фотодиод для фиксации изменения яркости точки на экране, и обеспечена симуляция работы USB-клавиатуры. Для вывода были задействованы видеокарта NVIDIA GeForce RTX 5070 и монитор LG 27GN950. В системе применялось ядро Linux 7.1.7 и набор проприетарных драйверов NVIDIA 610.57.04.

Linux / Линукс🥸

Оживляем старые ноутбуки

Linux / Линукс🥸