После дальнейшего тестирования выяснилось, что запускать 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 для угадывания системности пользователей.

надо посмотреть, а не будет ли firejail достаточно только root, текущего пользователя и nobody в jail.

потому что все системные пользователи выглядят лишними в изоляции.

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)

(Ответ для Mikhail Efremov на комментарий #5)
> Можно, в принципе, группу придумать для которой чтение login.defs разрешить.
Не решает, т.к. поддержка d-bus в такой программе автоматом выключается.

(Ответ для Mikhail Efremov на комментарий #7)
> непонятно зачем ей знать UID_MIN/GID_MIN нать в этом случае.
Потому, что её выделили в процесс, работающий не от root. Это все greeter-ы от DM-ов.

(Ответ для Dmitry V. Levin на комментарий #12)
> У нас полно установок, в которых через несколько лет после создания
> пользователей UID_MIN в login.defs увеличился с 500 до 1000.  Если следовать
> этому критерию, то все эти пользователи окажутся отфильтрованными.
А в чём проблема?
Админу достаточно вернуть взад UID_MIN и это не единственное, что придётся делать после обновления на новую версию.

(Ответ для Dmitry V. Levin на комментарий #19)
> Почему, скажем, greeter должен скрывать таких пользователей, если они
> могут залогиниться?
Потому, что подниматься по эскалатору, едущему вниз, неудобно.

(Ответ для Dmitry V. Levin на комментарий #20)
> Что касается самих прав на login.defs, то доступ на чтение позволяет
> установить блокировку, и раньше были опасения, что возможность устанавливать
> такую блокировку непривилегированными пользователями можно использовать для
> организации отказов в обслуживании
Ааа, ок. В этом случае не вижу проблемы вытащить UID_MIN и UID_MAX при установке пакета в персональный конфиг только для чтения остальным.

> Однако, если login.defs станет доступным на чтение, это, несомненно,
> подорвёт мотивацию исправлять код, который смотрит на UID_MIN для угадывания
> системности пользователей.
А где-то хоть одна мотивация произошла? :-)

*** Bug 59865 has been marked as a duplicate of this bug. ***

(Ответ для Sergey V Turchin на комментарий #27)
> (Ответ для Dmitry V. Levin на комментарий #20)
> > Что касается самих прав на login.defs, то доступ на чтение позволяет
> > установить блокировку, и раньше были опасения, что возможность устанавливать
> > такую блокировку непривилегированными пользователями можно использовать для
> > организации отказов в обслуживании
> Ааа, ок. В этом случае не вижу проблемы вытащить UID_MIN и UID_MAX при
> установке пакета в персональный конфиг только для чтения остальным.
В моём случае одному конкретному пользователю.