45710 2023-03-30 13:57:13 +0300 Невозможно использование firetools от имени обычного пользователя 2026-03-05 18:18:42 +0300 1 1 4 Development Sisyphus firejail unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 varaksaaa rider alxste ldv rider qa-sisyphus oldest_to_newest 223656 0 varaksaaa 2023-03-30 13:57:13 +0300 Описание проблемы ================= 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). 223835 1 varaksaaa 2023-04-03 12:52:01 +0300 После дальнейшего тестирования выяснилось, что запускать firetools от root лучше через: $ su - # firetools Тогда из интерфейса может запуститься больше приложений, например mousepad. (Но это не решает основную проблему - невозможность использования от обычного пользователя и невозможность запуска многих приложений даже с root.) 223839 2 varaksaaa 2023-04-03 13:37:46 +0300 При запуске через su, как описано выше, также становится возможным запуск приложений из интерфейса путём Configuration > выбрать приложение (например Network > Firefox) > Continue > Done. При этом Mousepad, например, всё равно явно сообщает о том, что запущен от суперпользователя. Firefox явно об этом не сообщает: возможно, сам Firefox или Firetools/Firejail как-то запускает Firefox не от имени суперпользователя при таком способе запуска? Но при этом запуск приложений нажатием иконок в Firetools всё равно не работает для многих приложений, как описано выше. 225171 3 13053 alxste 2023-04-28 17:37:39 +0300 Created attachment 13053 fix patch - waring вместо error, 500 вместо 1000 После локальной пересборки пакета с эти патчем, у меня firetools запустился из под обычного пользователя и работает. Суть патча - поменял MIN_UID и MIN_GID по умолчанию с 1000 на 500. Сообщение об ошибке изменил с Error на Warning 226126 4 rider 2023-05-19 14:29:48 +0300 На мой взгляд ошибка должна чиниться через права доступа к login.defs 226128 5 sem 2023-05-19 15:00:41 +0300 Ну, чем меньше не-root пользователи знают о конфигурации системы, тем лучше, конечно :). Можно, в принципе, группу придумать для которой чтение login.defs разрешить. Но может в login.defs и нет ничего настолько уж секретного все-таки. Хотелось бы мнение ldv@ услышать. 226129 6 ldv 2023-05-19 15:01:48 +0300 На мой взгляд, если программа привилегированная, то у неё уже есть доступ на чтение к файлу /etc/login.defs, а если не привилегированная, то ей не должно быть дела до содержимого этого файла, в частности, до значений UID_MIN и GID_MIN. 226131 7 sem 2023-05-19 15:11:31 +0300 (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 нарисовать, если это действительно нужно. 226134 8 rider 2023-05-19 15:23:20 +0300 авторы программы 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 В принципе я ничего критичного не увидел, на мой взгляд действия программы оправданы, а вот в связи с появлением двух вариантов этих параметров в репозитории - надо бы как-то научиться их получать. 226136 9 ldv 2023-05-19 15:54:10 +0300 Программа совершает логическую ошибку: она использует настройки создания новых пользователей для того, чтобы фильтровать уже созданных пользователей. Очень хорошо, что права на /etc/login.defs позволили выявить эту ошибку. 226146 10 rider 2023-05-19 18:55:44 +0300 А как её лучше исправить, на твой взгляд ? Какие ещё есть механизмы понять, что UID 501 ещё системный UID, а не пользователь системы ? 240602 11 rider 2024-01-25 10:57:08 +0300 Дима, можешь ответить на вопрос ? 240606 12 ldv 2024-01-25 11:43:18 +0300 (In reply to Anton Farygin from comment #11) > Дима, можешь ответить на вопрос ? Системность пользователя - это непонятная мне характеристика. Пусть авторы программы определятся, по какому критерию они хотят фильтровать пользователей, и фильтруют по нему. Например, по полю shell из списка /etc/shells. UID_MIN из login.defs - странный критерий, на мой взгляд. У нас полно установок, в которых через несколько лет после создания пользователей UID_MIN в login.defs увеличился с 500 до 1000. Если следовать этому критерию, то все эти пользователи окажутся отфильтрованными. Открыть login.defs всем на чтение - это значит просто замести все такие проблемы под ковёр. 240610 13 rider 2024-01-25 11:55:32 +0300 так авторы и определились - по UID_MIN. Вполне нормальный критерий, который используется при добавлении системных группы и пользователей. Что касается обновлений - так есть же useradd -r, там проблема точно такая (с обновлениями) - было 500, стало 1000. Как раз за счёт login.defs, который не должен изменять UID_MIN при обновлении это и должно решаться. Я могу сделать разные хаки для того, что бы получить значение UID_MIN в системе, но всё-таки хотелось бы сделать это не грязным способом. 242615 14 ldv 2024-03-06 00:03:01 +0300 (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 в установленной системе менять не запрещено. Просто не надо считать, что эта настройка описывает уже созданных пользователей, потому что она на это не рассчитана. Конечно, гораздо проще плыть по течению, делать "как все" и воспроизводить чужие ошибки. Но если мы не можем себе позволить сделать правильно, то зачем вообще было начинать? 242618 15 rider 2024-03-06 08:49:19 +0300 Дима, я не знаю другого способа. Подскажи, пожалуйста, как правильно или скажи где посмотреть (пример). Задача очень простая - отделить реальных пользователей от "системных". Ведь никто не запрещает создать "системного" пользователя со всеми признаками обычного - а именно разрешённый шелл или домашний каталог. Сейчас при отсутствии возможности прочитать login.defs в приложение хардкодится 1000 и это работает не на всех наших системах. 242619 16 rider 2024-03-06 08:51:44 +0300 Эти же механизмы, очевидно, должны использоваться во всех графических менеджерах для отделения системных пользователей от обычных. А сейчас там вот так: https://packages.altlinux.org/en/sisyphus/srpms/lightdm/specfiles/#line-208 242623 17 ldv 2024-03-06 09:46:57 +0300 (In reply to Anton Farygin from comment #15) > Дима, я не знаю другого способа. Подскажи, пожалуйста, как правильно или > скажи где посмотреть (пример). > > Задача очень простая - отделить реальных пользователей от "системных". > > Ведь никто не запрещает создать "системного" пользователя со всеми > признаками обычного - а именно разрешённый шелл или домашний каталог. Если "системный" пользователь отличается только номером uid'а, то в чём состоит его системность, и чем он менее реальный, чем "реальные" пользователи? 242626 18 rider 2024-03-06 10:08:11 +0300 Мне всегда казалось, что системный пользователь - это некий специальный пользователь, предназначенный для выполнения системных операций (запуска сервисов, приложений, скриптов, утилит). У системного пользователя может быть нестандартный домашний каталог, может отсутствовать (или присутствовать) шелл и быть UID ниже определённого в /etc/login.defs значении (который используется утилитой добавления пользователя для разделения - системный или обычный пользователь будет заведён). К сожалению невозможно гарантировать, что заведённый с помощью useradd -r пользователь будет обладать какими-то дополнительными (кроме UID) отличиями от обычного, рядового пользователя. 242629 19 ldv 2024-03-06 10:59:06 +0300 (In reply to Anton Farygin from comment #18) > К сожалению невозможно гарантировать, что заведённый с помощью useradd -r > пользователь будет обладать какими-то дополнительными (кроме UID) отличиями > от обычного, рядового пользователя. Ну вот мне остаётся непонятно, с какой целью пытаться отличать пользователей, заведённых с помощью useradd -r, если они отличаются только uid. Почему, скажем, greeter должен скрывать таких пользователей, если они могут залогиниться? 242630 20 ldv 2024-03-06 11:06:19 +0300 Что касается самих прав на login.defs, то доступ на чтение позволяет установить блокировку, и раньше были опасения, что возможность устанавливать такую блокировку непривилегированными пользователями можно использовать для организации отказов в обслуживании на всех, кто устанавливает такие блокировки на login.defs. С тех пор код shadow-utils мог сильно измениться в этой части, возможно, прежние опасения уже не актуальны. Однако, если login.defs станет доступным на чтение, это, несомненно, подорвёт мотивацию исправлять код, который смотрит на UID_MIN для угадывания системности пользователей. 283309 21 rider 2026-03-05 15:54:03 +0300 надо посмотреть, а не будет ли firejail достаточно только root, текущего пользователя и nobody в jail. потому что все системные пользователи выглядят лишними в изоляции. 283325 22 repository-robot 2026-03-05 18:18:42 +0300 firejail-0.9.78-alt3 -> sisyphus: Thu Mar 05 2026 Anton Farygin <rider@altlinux> 0.9.78-alt3 - skip unreadable files in private-etc instead of crashing (closes: #58112) - sandbox user isolation: only expose root, nobody and current user instead of using UID_MIN/GID_MIN threshold from /etc/login.defs (closes: #45710) - removed login.defs from default private-etc list (no longer needed at runtime) 13053 2023-04-28 17:37:39 +0300 2023-04-28 17:37:39 +0300 fix patch - waring вместо error, 500 вместо 1000 patch_uid_min.patch text/plain 540 alxste LS0tIGZpcmVqYWlsLTAuOS43Mi9zcmMvbGliL2ZpcmVqYWlsX3VzZXIuYy5vcmlnCTIwMjMtMDQt MjggMTU6NTk6NTcuNTc1Mzc4MTAzICswMzAwCisrKyBmaXJlamFpbC0wLjkuNzIvc3JjL2xpYi9m aXJlamFpbF91c2VyLmMJMjAyMy0wNC0yOCAxNTo1OTo1Ny41NzUzNzgxMDMgKzAzMDAKQEAgLTg3 LDkgKzg3LDkgQEAgc3RhdGljIHZvaWQgaW5pdF91aWRfZ2lkX21pbih2b2lkKSB7CiAJcmV0dXJu OwogCiBlcnJleGl0OgotCWZwcmludGYoc3RkZXJyLCAiRXJyb3I6IGNhbm5vdCByZWFkIFVJRF9N SU4gYW5kL29yIEdJRF9NSU4gZnJvbSAvZXRjL2xvZ2luLmRlZnMsIHVzaW5nIDEwMDAgYnkgZGVm YXVsdFxuIik7Ci0JdWlkX21pbiA9IDEwMDA7Ci0JZ2lkX21pbiA9IDEwMDA7CisJZnByaW50Zihz dGRlcnIsICJXYXJuaW5nOiBjYW5ub3QgcmVhZCBVSURfTUlOIGFuZC9vciBHSURfTUlOIGZyb20g L2V0Yy9sb2dpbi5kZWZzLCB1c2luZyA1MDAgYnkgZGVmYXVsdFxuIik7CisJdWlkX21pbiA9IDUw MDsKKwlnaWRfbWluID0gNTAwOwogfQogCiAK