SbindirPolicy

Помимо бессмысленного разделения /usr/{bin,sbin,lib} и аналогов этих каталогов в корне, столь же бессмысленным ныне является и разделение между /usr/bin и /usr/sbin. Этому разделению приводят различные обоснования:

Q: В sbin кладут статически собранные бинарники, которые могут работать при сбое динамического линковщика.

A: Это, мягко говоря, не так; да и в этом случае /usr/sbin и /sbin не были бы в PATH по умолчанию.

Q: В sbin кладут исполнимые файлы, пригодные только для запуска суперпользователем; их надо прятать от обычного пользователя, поэтому каталог /usr/sbin исключён из PATH непривилегированных пользователей.

A: В дистрибутиве общего назначения на сегодняшний день всё меньше таких программ, если они вообще существуют. Утилиты для настройки сетевых интерфейсов запускают без привилегий, чтобы узнать текущую конфигурацию. /sbin/fdisk и /sbin/mkfs.* работают на файлах-образах блочных хранилищ. /sbin/reboot безопасно завершает работу машины, если запустивший её пользователь работает за её локальным рабочим местом. Но — если включить сарказм — все эти программы надо спрятать от пользователя, чтобы шелл ему лгал, что такие команды не найдены, а вот малварь без исходников, никогда не вызываемую пользователем из командной оболочки, надо не прятать, а положить в PATH, чтобы она мешала шелльному автодополнению.

Кроме того, FHS гласит:

Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path.

For example, files such as chfn which users only occasionally use must still be placed in /usr/bin. ping, although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and must live in /bin for that reason.

We recommend that users have read and execute permission for everything in /sbin except, perhaps, certain setuid and setgid programs. The division between /bin and /sbin was not created for security reasons or to prevent users from seeing the operating system, but to provide a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. There is no inherent security advantage in making /sbin off-limits for users.

Совсем избавиться от /usr/sbin, однако, трудно: ядро и программа mount ищут вспомогательные линейные программы вроде /sbin/modprobe или /sbin/mount.* именно там.

В альте сложилась собственная полуосмысленная практика: некоторые программы из sbin в составе системных пакетов намеренно перекрывают другие программы из bin и могут быть исполнены только рутом:

# ls -l /usr/sbin/passwd
-rwx------ 1 root root 15064 Jul  1  2018 /usr/sbin/passwd
# ls -l /usr/bin/passwd
-rwx--s--x 1 root shadow 14552 Jul  1  2018 /usr/bin/passwd

Таким образом, execvp(3) без uid 0 пройдёт мимо /usr/sbin/passwd, даже если /usr/sbin у процесса в PATH стоит до /usr/bin. Достичь того же самого можно, поместив два варианта passwd в глубинный каталог, а в PATH оставив обёртку, запускающую нужную программу.

Мы предлагаем Если не искать лёгких путей и не объединять эти каталоги, то можно было бы предложить развить эту практику до полноценной:

• если стоит вопрос, bin или sbin, выбирать bin;
• ничего нового не класть в /usr/sbin по самоволию сопровождающего;
• в перспективе оставить там только то, что доступно для исполнения только руту, и пути-интерфейсы вроде /sbin/modprobe;
• в случаях, когда нужна ссылка /usr/sbin/x -> ../bin/x, как, например, предыдущий, делать жёсткую ссылку, а не символическую.

Эти правила, по идее, позволят сохранить корректность работы системы, если у не-рутов в PATH будут sbin-каталоги.