Описание проблемы ================= firejail при запуске без root не может прочитать файл /etc/login.defs: > Error: cannot read UID_MIN and/or GID_MIN from /etc/login.defs, using 1000 by default Что ожидаемо: > # l /etc/login.defs > -rw-r----- 1 root shadow 2801 мар 21 2022 /etc/login.defs Причём сам по себе firejail при этом работает нормально (без прав суперпользователя) и может запускать приложения. Однако firetools при запуске без root видит в выводе от `firejail /bin/true 2>&1` слово "Error" и решает, что firejail не работает (https://github.com/netblue30/firetools/blob/6953e2d6cc6d59b7b3f0e9b344effd3bd7a67c1b/src/firetools/mainwindow.cpp#L47-L53), поэтому не запускается: > Cannot run Firejail sandbox, you may not have the correct permissions to access this program. Запуск firetools, таким образом, необходимо производить с правами суперпользователя, используя: > # control sudowheel enabled > $ sudo firetools Однако дальнейшее использование firetools всё равно затруднено ввиду того, что многие приложения (firefox, vlc, chromium, pidgin, thunderbird, ...) отказываются запускаться с правами root. При их запуске из firetools в окне терминала название меняется, например, на "firetools firefox" и выводится сообщение вида "The new log directory is /proc/6596/root/var/log" (и, возможно, некоторые сообщения от самого приложения, например версия pidgin), но при этом больше ничего не происходит. Убедиться в том, что им не нравиться именно запуск с правами root, можно, выполнив: > $ sudo firefox > Running Firefox as root in a regular user's session is not supported. ($XAUTHORITY is /home/test/.Xauthority which is owned by test.) Ожидаемый результат: firetools должно быть можно запустить без прав суперпользователя (или хотя бы должна быть возможность разрешить это с помощью control). Замечания ========= Для запуска firetools может потребоваться создать папку /root/.config (в общем случае ~/.config), если она не существует (см. https://github.com/netblue30/firetools/issues/72). Воспроизводимость ================= Пакеты ------ firejail-0.9.72-alt1.x86_64 firetools-0.9.72-alt1.x86_64 Воспроизводимость в Sisyphus ---------------------------- Воспроизводится. Стенды, обновлённые до Sisyphus: education-10.1-x86-64 education-10.1-x86-64-kde Воспроизводимость в p10 ----------------------- Проверялось в p10 (с задачей 317165), ошибка воспроизводится. Стенды p10: kworkstation-10.1-x86-64 education-10.1-x86-64 education-10.1-x86-64-kde workstation-10.1-x86-64 server-10.1-x86-64 Проверка на регресс в p10 ------------------------- Также воспроизводится с версиями: firejail-0.9.64.4-alt2 firetools-0.9.64-alt1 на стенде education-10.1-x86-64 (p10).
После дальнейшего тестирования выяснилось, что запускать firetools от root лучше через: $ su - # firetools Тогда из интерфейса может запуститься больше приложений, например mousepad. (Но это не решает основную проблему - невозможность использования от обычного пользователя и невозможность запуска многих приложений даже с root.)
При запуске через su, как описано выше, также становится возможным запуск приложений из интерфейса путём Configuration > выбрать приложение (например Network > Firefox) > Continue > Done. При этом Mousepad, например, всё равно явно сообщает о том, что запущен от суперпользователя. Firefox явно об этом не сообщает: возможно, сам Firefox или Firetools/Firejail как-то запускает Firefox не от имени суперпользователя при таком способе запуска? Но при этом запуск приложений нажатием иконок в Firetools всё равно не работает для многих приложений, как описано выше.
Created attachment 13053 [details] fix patch - waring вместо error, 500 вместо 1000 После локальной пересборки пакета с эти патчем, у меня firetools запустился из под обычного пользователя и работает. Суть патча - поменял MIN_UID и MIN_GID по умолчанию с 1000 на 500. Сообщение об ошибке изменил с Error на Warning
На мой взгляд ошибка должна чиниться через права доступа к login.defs
Ну, чем меньше не-root пользователи знают о конфигурации системы, тем лучше, конечно :). Можно, в принципе, группу придумать для которой чтение login.defs разрешить. Но может в login.defs и нет ничего настолько уж секретного все-таки. Хотелось бы мнение ldv@ услышать.
На мой взгляд, если программа привилегированная, то у неё уже есть доступ на чтение к файлу /etc/login.defs, а если не привилегированная, то ей не должно быть дела до содержимого этого файла, в частности, до значений UID_MIN и GID_MIN.
(In reply to Dmitry V. Levin from comment #6) > На мой взгляд, если программа привилегированная, то у неё уже есть доступ на > чтение к файлу /etc/login.defs, а если не привилегированная, то ей не должно > быть дела до содержимого этого файла, в частности, до значений UID_MIN и > GID_MIN. Ну тут вот как раз хотят программу под не привилегированным пользователем запускать. Но мне тоже непонятно зачем ей знать UID_MIN/GID_MIN нать в этом случае. (In reply to Mikhail Efremov from comment #5) > Можно, в принципе, группу придумать для которой чтение login.defs разрешить. Еще можно просто control для login.defs с public, wheelonly, restricted нарисовать, если это действительно нужно.
авторы программы firejail используют uid_min и gid_min в этом месте: https://git.altlinux.org/gears/f/firejail.git?p=firejail.git;a=blob;f=src/firejail/restrict_users.c;h=447d7b6635972363b3bd05f410002b25ed76384e;hb=c100d7f97da2f277c2ea0aa01608b00f5392d4df В принципе я ничего критичного не увидел, на мой взгляд действия программы оправданы, а вот в связи с появлением двух вариантов этих параметров в репозитории - надо бы как-то научиться их получать.
Программа совершает логическую ошибку: она использует настройки создания новых пользователей для того, чтобы фильтровать уже созданных пользователей. Очень хорошо, что права на /etc/login.defs позволили выявить эту ошибку.
А как её лучше исправить, на твой взгляд ? Какие ещё есть механизмы понять, что UID 501 ещё системный UID, а не пользователь системы ?
Дима, можешь ответить на вопрос ?
(In reply to Anton Farygin from comment #11) > Дима, можешь ответить на вопрос ? Системность пользователя - это непонятная мне характеристика. Пусть авторы программы определятся, по какому критерию они хотят фильтровать пользователей, и фильтруют по нему. Например, по полю shell из списка /etc/shells. UID_MIN из login.defs - странный критерий, на мой взгляд. У нас полно установок, в которых через несколько лет после создания пользователей UID_MIN в login.defs увеличился с 500 до 1000. Если следовать этому критерию, то все эти пользователи окажутся отфильтрованными. Открыть login.defs всем на чтение - это значит просто замести все такие проблемы под ковёр.
так авторы и определились - по UID_MIN. Вполне нормальный критерий, который используется при добавлении системных группы и пользователей. Что касается обновлений - так есть же useradd -r, там проблема точно такая (с обновлениями) - было 500, стало 1000. Как раз за счёт login.defs, который не должен изменять UID_MIN при обновлении это и должно решаться. Я могу сделать разные хаки для того, что бы получить значение UID_MIN в системе, но всё-таки хотелось бы сделать это не грязным способом.
(In reply to Anton Farygin from comment #13) > так авторы и определились - по UID_MIN. Вполне нормальный критерий, который > используется при добавлении системных группы и пользователей. > > Что касается обновлений - так есть же useradd -r, там проблема точно такая > (с обновлениями) - было 500, стало 1000. Как раз за счёт login.defs, который > не должен изменять UID_MIN при обновлении это и должно решаться. > > Я могу сделать разные хаки для того, что бы получить значение UID_MIN в > системе, но всё-таки хотелось бы сделать это не грязным способом. Повторяю ещё раз: UID_MIN - это настройка для useradd, а не для пользователей. Эта настройка говорит, как создавать новых пользователей. Она не говорит, как трактовать пользователей, созданных ранее. UID_MIN в установленной системе менять не запрещено. Просто не надо считать, что эта настройка описывает уже созданных пользователей, потому что она на это не рассчитана. Конечно, гораздо проще плыть по течению, делать "как все" и воспроизводить чужие ошибки. Но если мы не можем себе позволить сделать правильно, то зачем вообще было начинать?
Дима, я не знаю другого способа. Подскажи, пожалуйста, как правильно или скажи где посмотреть (пример). Задача очень простая - отделить реальных пользователей от "системных". Ведь никто не запрещает создать "системного" пользователя со всеми признаками обычного - а именно разрешённый шелл или домашний каталог. Сейчас при отсутствии возможности прочитать login.defs в приложение хардкодится 1000 и это работает не на всех наших системах.
Эти же механизмы, очевидно, должны использоваться во всех графических менеджерах для отделения системных пользователей от обычных. А сейчас там вот так: https://packages.altlinux.org/en/sisyphus/srpms/lightdm/specfiles/#line-208
(In reply to Anton Farygin from comment #15) > Дима, я не знаю другого способа. Подскажи, пожалуйста, как правильно или > скажи где посмотреть (пример). > > Задача очень простая - отделить реальных пользователей от "системных". > > Ведь никто не запрещает создать "системного" пользователя со всеми > признаками обычного - а именно разрешённый шелл или домашний каталог. Если "системный" пользователь отличается только номером uid'а, то в чём состоит его системность, и чем он менее реальный, чем "реальные" пользователи?
Мне всегда казалось, что системный пользователь - это некий специальный пользователь, предназначенный для выполнения системных операций (запуска сервисов, приложений, скриптов, утилит). У системного пользователя может быть нестандартный домашний каталог, может отсутствовать (или присутствовать) шелл и быть UID ниже определённого в /etc/login.defs значении (который используется утилитой добавления пользователя для разделения - системный или обычный пользователь будет заведён). К сожалению невозможно гарантировать, что заведённый с помощью useradd -r пользователь будет обладать какими-то дополнительными (кроме UID) отличиями от обычного, рядового пользователя.
(In reply to Anton Farygin from comment #18) > К сожалению невозможно гарантировать, что заведённый с помощью useradd -r > пользователь будет обладать какими-то дополнительными (кроме UID) отличиями > от обычного, рядового пользователя. Ну вот мне остаётся непонятно, с какой целью пытаться отличать пользователей, заведённых с помощью useradd -r, если они отличаются только uid. Почему, скажем, greeter должен скрывать таких пользователей, если они могут залогиниться?
Что касается самих прав на login.defs, то доступ на чтение позволяет установить блокировку, и раньше были опасения, что возможность устанавливать такую блокировку непривилегированными пользователями можно использовать для организации отказов в обслуживании на всех, кто устанавливает такие блокировки на login.defs. С тех пор код shadow-utils мог сильно измениться в этой части, возможно, прежние опасения уже не актуальны. Однако, если login.defs станет доступным на чтение, это, несомненно, подорвёт мотивацию исправлять код, который смотрит на UID_MIN для угадывания системности пользователей.
