Linux usr bin false

Еще одно мнение о разнице между bin, sbin, usr/bin, usr/sbin

Недавно я обнаружил вот такую статью: Разница между bin, sbin, usr/bin, usr/sbin. Хотелось бы поделиться своим взглядом на стандарт.

Содержит команды, которые могут использоваться как системным администратором, так и пользователями, но которые необходимы, когда не смонтированы никакие другие файловые системы (например, в однопользовательском режиме). Он также может содержать команды, которые косвенно используются скриптами.

Там ожидается присутствие таких команд:

Можно сделать симлинки на /usr, но хотя во времена systemd /usr на отдельном устройстве не встречается, его еще можно встретить на встраиваемой системе, светофоре, кофемолке и PDP-11 обслуживающем важный прибор в одной из лабораторий Академии Наук.

Утилиты, используемые для системного администрирования (и другие команды только для root), /sbin содержит двоичные файлы, необходимые для загрузки, восстановления, восстановления и/или восстановления системы в дополнение к двоичным файлам в /bin. Программы, выполняемые после того, как /usr монтируется (когда проблем нет), обычно помещаются в /usr/sbin. Локально установленные программы системного администрирования должны быть помещены в /usr/local/sbin.

fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update.

Один из способов защиты системы от шаловливых рук юзеров — это запрет запуска этих утилит кому-попало, установкой атрибута x.
К тому же, замена /bin и /sbin на копии из архива (одинакового для всех однотипных систем) является быстрым способом починки систем без пакетного менеджера.

/usr/bin

Тут всё просто. Однотипные команды, одинаковые для всех серверов/кофемолок компании. И сам /usr может разворачиваться одинаковым для разных ОС (для /bin и /sbin такое как правило не работает), это архитектурно независимые программы. Может содержать линки на интерпретаторы perl или python, которые лежат в /opt или еще где-то в сети.

/usr/sbin

Тоже самое, что /usr/bin, но для использования только админами.

/usr/local/bin и /usr/local/sbin

Одна из важнейших локаций. В отличие от остального, /usr не может быть одинаковой для всей организации. Тут находятся ОС-зависимые, hardware-зависимые и просто программы, которые не на всех устройствах нужны. При синхронизации /usr на машинах, /usr/local требуется исключать.

/home/$USER/bin

Тут случай аналогичный с /usr/local, только лежат программы специфичные для конкретного пользователя. Можно переносить (или синхронизировать) на другую машину при переезде пользователя. То, что нельзя переносить складывается в /home/$USER/.local/bin. Можно использовать local без точки. /home/$USER/sbin по понятным соображениям отсутствует.

Источник

Разница между bin, sbin, usr/bin, usr/sbin

Я заметил, что в busybox ссылки разложены по этим четырём директориям.
Есть ли какое-то простое правило, чтобы определить, в какой директории какая из ссылок должна лежать…
К примеру, kill лежит в /bin, а killall — в /usr/bin… Я не вижу никакой логики в таком разделении.

Вы, наверное, знаете, что Кен Томпсон и Дэннис Ритчи создали Unix на PDP-7 в 1969-ом. Так вот, примерно в 1971 они проапгрейдились до PDP-11 с парой дисков RK05 (по 1,5 мегабайта каждый).

Когда операционная система разрослась и перестала помещаться на первом диске (на котором была расположена корневая ФС), они перенесли часть на второй, где располагались домашние директории (поэтому точка монтирования называлась /usr — от слова user). Они продублировали там все необходимые директории ОС (/bin, /sbin, /lib, /tmp . ) и складывали файлы на новый диск, потому что на старом кончилось место. Потом у них появился третий диск, они примонтировали его в директории /home и перенесли туда домашние директории пользователей, чтобы ОС могла занять всё оставшееся место на двух дисках, а это были целых три мегабайта (огого!).

Разумеется, им пришлось ввести правило, что «когда операционная система загружается, она должна быть в состоянии примонтировать второй диск в директорию /usr, поэтому не надо класть программы типа mount на второй диск в /usr, а то получим проблему курицы и яйца». Вот так просто. И это относилось к Unix V6 35 лет назад.

Разделение /bin и /usr/bin (и всех подобных директорий) — это последствие тех событий, деталь реализации из 70-х, которая до сих пор, в течение десятилетий, копировалась бюрократами. Они никогда не задавали вопрос почему, они просто делали так. Это разделение перестало иметь смысл ещё до того, как Linux был создан, по нескольким причинам:

1. При загрузке используется initrd или initramfs, который берёт на себя проблемы типа «этот файл нам нужен раньше чем тот». Таким образом, у нас уже есть временная файловая система, которая используется для загрузки всего остального.
2. Разделяемые библиотеки (которые были добавлены в Unix ребятами из Berkley) не позволяют вам независимо менять содержимое /lib и /usr/lib. Эти две части должны соответствовать друг другу, иначе они не будут работать. Этого не происходило в 1974-ом, поскольку тогда у них была некоторая независимость из-за статической линковки.
3. Дешёвые жёсткие диски преодолели барьер в 100 мегабайт где-то в 1990-ом и примерно в то же время появились программы для изменения размера разделов (partition magic 3.0 вышла в 1997-ом).

Разумеется, поскольку разделение есть, некоторые люди придумали правила, которые его оправдывают. Типа, корневой раздел нужен для всяких общих штучек ОС, а в /usr надо класть свои локальные файлы. Или в / помещают то, что распространяет AT&T, а в /usr — то, что твой дистрибутив, IBM AIX, или Dec Ultrix, или SGI Irix добавили, а в /usr/local лежат файлы, специфичные для твоей системы. А потом кто-то решил, что /usr/local — это не подходящее место, чтобы туда устанавливать новый софт, так что давайте ещё добавим /opt! Не удивлюсь, если появится ещё и /opt/local…

Разумеется, за 30 лет из-за такого разделения появлялись и исчезали всякие интересные специфичные для отдельных дистрибутивов правила. Например, «/tmp очищается при перезагрузке, а /usr/tmp — нет». (И в Ubuntu /usr/tmp нет в принципе, а в Gentoo /usr/tmp — это символическая ссылка на /var/tmp, на который теперь распространяется то правило, и он не очищается при перезагрузке. Да, это всё было ещё до tmpfs. А ещё бывает, что корневая ФС доступна только на чтение, и тогда в /usr тоже не надо ничего писать, а надо писать в /var. Или в / в основном нельзя писать, не считая того, что в /etc, которую иногда пытались перенести в /var. )

Бюрократы вроде Linux Foundation (которые поглотили Free Standards Group во время расширения годы назад) с радостью документируют и усложняют эти правила, даже не пытаясь понять, почему они появились. Они не догадываются, что Кен и Дэннис просто перенесли часть ОС в их домашнюю директорию, из-за того, что диск RK05 на PDP-11 был слишком мал.

Я практически уверен, что в busybox просто помещает файлы так же, как это исторически сложилось. Нет никакой реальной причины делать так до сих пор. Лично я просто делаю /bin, /sbin и /lib ссылками на аналогичные директории в /usr. Ведь люди, которые работают со встраиваемым софтом, стараются разбираться и упрощать…

Источник

Linux /bin/false VS /sbin/nologin: Politely Refuse a Login

H ow do I deny access to user account? Do I need to use /bin/false or /sbin/nologin to refuse a login?

The /sbin/nologin command politely refuse a login. It displays a message that an account is not available and exits non-zero. This is prefreed method these days to deny login access to account. You can use it as follows:
# usermod -s /sbin/nologin userName

The /bin/false is old method which does nothing and always return unsuccessful code. You can use it as follows to deny login access to existing user:
# usermod -s /bin/false userName

More About /etc/nologin File

If the file /etc/nologin exists, login will allow access only to root user. ther users will be shown the contents of this file and their logins will be refused. This is used when you need to deny login access to all users except root account. Just create /etc/nologin file and you are done:
cat > /etc/nologin
Sample ouputs:

• No ads and tracking
• In-depth guides for developers and sysadmins at Opensourceflare✨
• Join my Patreon to support independent content creators and start reading latest guides:
  • How to set up Redis sentinel cluster on Ubuntu or Debian Linux
  • How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
  • How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
  • A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
  • How to protect Linux against rogue USB devices using USBGuard

Join Patreon ➔

A Better Solution

Lock and unlock user accounts using the following commands:
# passwd -l userName
To unlock it again:
# passwd -u userName

🐧 Get the latest tutorials on Linux, Open Source & DevOps via

Источник

В чем разница между /sbin /nologin и /bin /false?

Я часто слышал, что рекомендуется отключить учетную запись пользователя, установив ее оболочку в /bin/false . Но, по моим существующим системам Linux, я вижу, что у большого количества существующих учетных записей (все из них учетные записи служб) вместо этого есть оболочка /sbin/nologin .

Я вижу на странице man, что /sbin/nologin печатает сообщение пользователю, говоря, что учетная запись отключена, а затем завершает работу. Предположительно /bin/false ничего не печатает.

Я также вижу, что /sbin/nologin указан в /etc/shells , а /bin/false — нет.

На странице руководства говорится, что FTP отключит доступ для пользователей с оболочкой not , указанной в /etc/shells , и подразумевает, что другие программы могут сделать то же самое. Означает ли это, что кто-то может подключаться к FTP с учетной записью с /sbin/nologin в качестве оболочки?

В чем тут разница? Какой из них я должен использовать для отключения учетной записи пользователя и при каких обстоятельствах? Какие еще эффекты имеет листинг в /etc/shells ?

3 ответа

/bin/false — это служебная программа, сопутствующая /bin/true , которая полезна в каком-то абстрактном смысле, чтобы убедиться, что unix полностью дополнен. Однако были найдены новые цели для этих программ; рассмотрим инструкцию BASH /some/program || /bin/true , который всегда будет иметь значение boolean для true ( $? = 0 ) независимо от возврата /some/program .

Внезапное использование /bin/false , как вы определили, является пустой оболочкой для пользователей, которым не разрешено входить в систему. Система в этом случае будет вести себя точно так же, как если бы оболочка не удалась работать.

POSIX (хотя я могу ошибаться, и это может быть SUS) ограничивает обе эти команды только тем, что возвращает только соответствующее логическое значение.

/sbin/nologin — это утилита BSD, которая имеет аналогичное поведение с /bin/false (возвращает boolean false), но также выводит вывод, как /bin/false запрещается делать. Это должно помочь пользователю понять, что произошло, хотя на практике многие терминальные эмуляторы просто закрываются, когда оболочка завершается, и в некоторых случаях сообщение все равно нечитаемо.

Существует мало возможностей для перечисления /sbin/nologin в /etc/shells . Стандартный эффект /etc/shells заключается в том, чтобы отображать программы, допустимые для использования с chsh , когда пользователи меняют свою собственную оболочку (и нет убедительной причины для изменения вашей собственной shell для /sbin/nologin ). Суперпользователь может изменить чью-либо оболочку на что угодно. Однако вы можете указать как /sbin/nologin , так и /bin/false в /etc/rsh , что запретит пользователям с этими оболочки из-за изменения оболочки с помощью chsh в неудачном случае, что они получают оболочку.

FTP-демоны могут запретить доступ к пользователям с оболочкой, не находящейся в /etc /shells, или они могут использовать любую другую логику, которую они хотят. Запускать FTP следует избегать в любом случае, потому что sftp (который обеспечивает аналогичную функциональность) аналогичен, но безопасен. Некоторые сайты используют /sbin/nologin , чтобы отключить доступ к оболочке, разрешая доступ sftp, помещая его в /etc/shells . Это может открыть бэкдор, если пользователю разрешено создавать cronjobs.

В любом случае scp не будет работать с недопустимой оболочкой. scponly может использоваться как оболочка в этом экземпляре.

Кроме того, выбор оболочки влияет на работу su — (AKA su -l ). В частности, вывод /sbin/nologin будет напечатан на stdout, если это оболочка; это не может быть в случае с кодом /bin/false . В любом случае команды, выполняемые с помощью su -cl , не будут выполнены.

Чтобы отключить учетную запись, не зависеть ни от одного из них, но установите оболочку в /sbin/nologin для информационных целей (если только /sbin/nologin не находится в /etc/shells , в этот момент вы должны использовать /bin/false , чего не должно быть). Вместо этого установите поле пароля в /etc/passwd в ! , что гарантируется crypt , чтобы оно не было действительным для каких-либо паролей. Рассмотрите возможность установки хэша в /etc/shadow таким же образом, чтобы избежать ошибок. passwd -l сделает это за вас.

Третий способ отключить учетную запись — установить поле даты истечения срока действия учетной записи на древнюю дату (например, usermod —expiredate 1 ). Это предотвратит вход в систему, если ваша настройка позволяет пользователям аутентифицироваться против их учетной записи unix без пароля, а служба, которую они используют, не требует оболочки.

После некоторых исследований по этому методу используемый вами метод зависит от того, что вам нужно заблокировать. Если пользователь входит в систему с этим набором в оболочку, тогда они получат сообщение, отображаемое с эффектом This account is currently unavailable. Обратите внимание, что вы можете изменить это, создав файл /etc/nologin.txt по крайней мере на производных RHEL.

Как вы знаете, /bin/false не является оболочкой. Как он работает, так это то, что он возвращает false, который выходит из системы сразу после двоичных выходов. Обратите внимание, что /bin/true достигнет того же эффекта.

Относительно вашего FTP-вопроса: Да, вы правы в том, что наличие оболочки, установленной в /sbin/nologin , позволит пользователям подключаться к FTP, а /bin/false или /bin/true полностью запретит пользователю входить в службу any .

Поэтому /bin/false или /bin/true лучше всего запретить пользователю входить в любую службу, а /sbin/nologin будет по-прежнему позволять пользователям входить в сервисы, отличные от SSH или локальной консоли, обеспечивая при этом обратную связь с пользователем, что учетная запись неактивна, и ее лучше всего использовать, когда нужно заблокировать только SSH /локальную консоль.

Um, попросил ли кто-нибудь попробовать доказать, что /bin /false запретит доступ к FTP?

Я только что изменил оболочку моего пользователя на /bin /false и смог полностью FTP.

Я использую /dev /null для полностью блокирует пользователя (ну, кроме электронной почты, они могут по-прежнему POP3).

Источник