procfs hidepid

Наверное потому что по факту малое количество машин используется в многопользовательском режиме где включение этого флажка может оправдано

Наверное для того, чтобы приложения имели доступ к этой информации. Например менеджеры процессов.

Но менеджер процессов, запущеный одним юзером, как раз не должен ничего знать про процессы другого. Знать всё про всех должен рут, но его эта опция не ограничивает.

Не обязательно многопользовательский. Вот запустил ты что-то от nobody, думая что оно потеряло доступ к твоим данным, а оно через командную строку одного из твоих процессов что-нить украло.

докер/кубер/firejail, ну и как правильно подметили выше - что-то многопользовательское-изолированное друг от друга.
а на условном десктопе с кедами или чем-то ещё, огородив себя можно что-то интересное и пропустить, кмк.

И правда, зачем настраивать безопасность простыми инструментами (опция монтирования procfs), когда можно поставить всякую муть и обложиться костыльными контейнерами?

а на условном десктопе с кедами или чем-то ещё, огородив себя можно что-то интересное и пропустить, кмк.

Если «менеджеру процессов» нужен полный список процессов, то персонально ему можно выдать такие права. Зачем при этом их открывать всем подряд, непонятно.

костыльными контейнерами

так оно из этого и состоит - unshare + netns + cgroups + hidepid

Если «менеджеру процессов» нужен полный список процессов

так он от рута работает, ему всёравно на hidepid

так оно из этого и состоит - unshare + netns + cgroups + hidepid

Тут целых три лишних компонента ради одного нужного.

как раз не должен ничего знать про процессы другого

Кто он другой, живой? Тогда рекомендуется с hidepid=2

Админы справятся где прописать, а простому и единственному владельцу ноутбука информация о процессах других пользователей (root, polkitd, systemd* и т.д.) скорее полезна, чем параноидальна.

То есть ты думаешь что единственная причина дефолтного 0 - угодить нубам которые иначе не разберутся как посмотреть системные процессы?

Кто он другой, живой? Тогда рекомендуется с hidepid=2

Какая разница? Вебсервер например явно не должен знать процессы десктопной сессии.

Вебсервер например явно не должен знать процессы десктопной сессии.

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

Вебсервер например явно не должен знать процессы десктопной сессии.

через его systemd-unit прописываешь как ресурсы(cpu/ram limits) так и ProtectProc=
https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
Цитата:

ProtectProc=
Takes one of "noaccess", "invisible", "ptraceable" or "default" (which it defaults to). When set, this controls the "hidepid=" mount option of the "procfs" instance for the unit that controls which directories with process metainformation (/proc/PID) are visible and accessible: when set to "noaccess" the ability to access most of other users' process metadata in /proc/ is taken away for processes of the service. When set to "invisible" processes owned by other users are hidden from /proc/. If "ptraceable" all processes that cannot be ptrace()'ed by a process are hidden to it. If "default" no restrictions on /proc/ access or visibility are made. For further details see The /proc Filesystem. It is generally recommended to run most system services with this option set to "invisible". This option is implemented via file system namespacing, and thus cannot be used with services that shall be able to install mount points in the host file system hierarchy. Note that the root user is unaffected by this option, so to be effective it has to be used together with User= or DynamicUser=yes, and also without the "CAP_SYS_PTRACE" capability, which also allows a process to bypass this feature. It cannot be used for services that need to access metainformation about other users' processes. This option implies MountAPIVFS=.

If the kernel does not support per-mount point hidepid= mount options this setting remains without effect, and the unit's processes will be able to access and see other process as if the option was not used.

This option is only available for system services and is not supported for services running in per-user instances of the service manager.

Added in version 247.

Нафига эта нестандартная и усложнённая обёртка над hidepid, когда hidepid есть нативно в ядре?

можете и bash-портянку для вашего предпочитаемого init-сервиса написать - дело вкуса и предпочтений.
hidepid, cgroup, netns это всего лишь ресурсы предоставляемые ядром.
инструменты - systemd/sysVinit/docker/kubernetes и т.д. используют их для решения Ваших задач.

Какую ещё баш портянку? Одну строчку в /etc/fstab добавляешь!

proc /proc proc rw,hidepid=2 0 0

это глобально, а ещё можно per-service. я про это.

Вебсервер например явно не должен знать процессы десктопной сессии.

Слово «например» видишь? О том чтобы ограничивать персонально веб-сервер, речи не шло, это был пример. Речь о том разделение на юзеров, даже если физический пользователь один, не для красоты, а как раз для изоляции доступов к данным. Список процессов - такие же данные, непонятно зачем ему какие-то исключения делать.

Так добавь. Ты разрешение всея лора спрашиваешь или в чем цель топика? Тебе так кажется правильным - сделай

Наверное потому что по факту малое количество машин используется в многопользовательском режиме где включение этого флажка может оправдано

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

Это задача администратора, а не обычных пользователей

Рачёты за пользователей админ запускать не будет

а зачем менять дефолт, если systemctl status всё равно выдаст все процессы с пидами, а дальше можно лазить по /proc используя то, что оно выдало?

В фрибсд всегда настраивал сокрытие чужих процессов, и даже инсталлятор там предлагает это сделать (с некоторых пор)

Ну все сходится. FreeBSD для работы на серверах. А линукс так, поиграться на десктопе)

Нет. Но если пользователю нужна какая-то нестандартная аллокация ресурсов, то стоит это обсудить с администратором машины