Bin false что это

Записки IT специалиста

Linux — начинающим. Часть 6. Управление пользователями и группами. Теория

Автор: Уваров А.С.
14.12.2019

Пользователи окружают нас всюду, в современных информационных системах это одно из ключевых понятий, вокруг которого строится вся система разграничения прав доступа и безопасности. Поэтому умение управлять пользователями и группами — это один из основных навыков необходимых любому администратору. Базовые механизмы управления пользователями и доступом в Linux достаточно просты и некоторым могут показаться грубыми, но нельзя осваивать более сложные механизмы, не обладая базовыми навыками, поэтому давайте начинать изучение этой непростой темы с самых ее азов.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Чтобы понять современную систему пользователей в Linux сделаем небольшой экскурс в историю. Как известно, Линус Торвальдс создавал ОС по образу и подобию UNIX и поэтому в основе Linux лежат многие простые и изящные решения этой системы. Одна из замечательных абстракций UNIX — это все есть файл, т.е. файлами также являются устройства, процессы, сетевые сокеты и т.д. и т.п. Это позволяет делать при помощи достаточно простых инструментов довольно сложные вещи, например, чтобы сделать образ диска достаточно просто скопировать файл блочного устройства в файл образа, а для работы с последовательным портом достаточно прочитать или записать что-либо в файл устройства ввода-вывода.

У каждого файла обязательно есть владелец и группа, которой он принадлежит. На этой схеме строится классическая система прав в Linux и UNIX: владелец, группа и остальные. Более подробно о ней вы можете прочитать в предыдущих частях нашего цикла:

Linux — начинающим. Часть 4. Работаем с файловой системой. Теория
Linux — начинающим. Часть 4. Работаем с файловой системой. Практика

Таким образом пользователи и группы определяют доступ не только к файлам в привычном нам понимании, но и ко всему спектру объектов операционной системы: процессам, устройствам, сокетам. Просто запомните, что все есть файл, а каждый файл имеет владельца и группу.

Условно всех пользователей можно разделить на специальных, служебных и обычных, но повторимся еще раз — деление это условное, все различие между ними заключается в предоставляемых им правах и некоторых иных возможностях. Чтобы получить список пользователей системы откроем файл /etc/passwd:

Давайте рассмотрим его структуру подробнее. Каждая строка соответствует одному пользователю и имеет следующий формат:

имя пользователя:пароль:UID:GID:комментарий:домашняя директория:командная оболочка

С именем пользователя все понятно, а вот второй параметр может вызвать некоторое недоумение. Когда-то давно пароли хранились в открытом виде, о чем намекает само название файла, но затем от этой практики отказались и современные системы не хранят пароли в каком-либо виде вообще, хранится только сформированный по специальному алгоритму хеш, такие пароли в Linux называются затененными ( shadow). Для такого пароля во втором поле всегда ставится символ x.

UID (User identifier) и GID (Group identifier) — числовые идентификаторы пользователя и группы. Важно понимать, что система различает пользователей именно по UID, а не по наименованиям и многие системы имеют возможность создать несколько пользователей с одинаковым UID, с точки зрения системы это будет один и тот же пользователь.

Этим часто пользуются злоумышленники, один из типовых сценариев проникновения предусматривает создание пользователя с неприметным именем, но идентификаторами root, что позволяет действовать в системе от имени суперпользователя не привлекая ненужного внимания.

В реальных сценариях данную возможность использовать не следует, так как наличие таких пользователей может вызвать конфликты в системе. Например, Gnome 3 в Debian 10 просто отказался загружаться после того, как мы создали такого пользователя.

В поле комментарий можно написать все что угодно, определенного формата в современных системах нет, но исторически данное поле называется GECOS и подразумевает перечисление через запятую следующих опций:

Полное имя пользователя, адрес офиса или домашний адрес, рабочий телефон, домашний телефон

Следующие два поля указывают на домашнюю директорию пользователя и его командную оболочку. Разным пользователям можно назначить разные командные оболочки, скажем, ваш коллега предпочитает zsh, то вы можете без проблем назначить ему любимую оболочку.

Рассмотрение командных оболочек Linux выходит за рамки данной статьи, поэтому мы оставим эту тему, но расскажем о двух специализированных «оболочках», которые указывают, когда пользователю запрещен интерактивный вход в систему. Это обычно применяется для служб и пользователей от имени которых исполняются некоторые скрипты. Даже если такая учетная запись будет скомпрометирована войти в консоль с ней не удастся.

Обычно для этой цели используется:

/usr/sbin/nologin

/sbin/nologin

В современных системах директория /sbin является символической ссылкой на /usr/sbin. Реже используется «оболочка»:

/bin/false

Разница между ними заключается в том, что /bin/false просто запрещает вход в систему, а /sbin/nologin выдает сообщение:

This account is currently not available.

Как мы уже говорили выше, всех пользователей можно условно разделить на три группы. К специальным пользователям относятся root (суперпользователь) и nobody (с группами root и nogroup). Это практически полные противоположности, root имеет наименьшие UID и GID — 0 и является обладателем неограниченных прав, он имеет доступ к любому объекту системы и может выполнять любые настройки. В отличие от Администратора Windows, который максимально огражден от деструктивных действий, root может с легкостью уничтожить систему.

Мы думаем, что следующая команда известна каждому, а некоторым — печально известна:

rm -rf /

Предупреждение! Данная команда уничтожает корневую файловую систему, что приводит к ее полной неработоспособности и потере всех данных. Приведена сугубо в качестве примера.

Современные дистрибутивы по умолчанию блокируют выполнение явно деструктивных команд, но не запрещают их, все это выглядит как предупреждение: «так делать опасно, но если ты настаиваешь. «

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

Хорошая практика — сделать учетную запись root недоступной для интерактивного входа (как в Ubuntu) используя для повышения прав исключительно sudo, особенно это касается серверов с доступом к SSH из сети интернет.

Пользователь nobody (никто) — имеет наибольший идентификатор — 65534 и не может являться владельцем ни одного файла в системе, не состоит ни в одной привилегированной группе и не имеет никаких полномочий кроме стандартных. Используется для запуска от его имени процессов с низким уровнем доверия, чтобы ограничить их доступ к системе в случае возможной компрометации. Фактически к nobody будут всегда применяться права для «остальных» и при стандартных наборах привилегий 644 на файлы и 755 на директории он будет иметь возможность исключительно чтения и просмотра содержимого каталогов. Для чувствительных конфигурационных файлов, ключей и сертификатов используются более ограниченные наборы прав 640 или 600, к таким файлам nobody доступа не имеет.

Следующая условная группа — системные пользователи, которые используются для запуска служб и доступа к устройствам, например, www-data для веб-сервера или systemd-network для управления сетью через systemd. Первоначально для них выделялись идентификаторы от 1 до 100, но в связи с большим количеством служб в современных системах этот диапазон расширен до 499 в RHEL и производных от него, и до 999 в системах основанных на Debian.

Существует соглашение, что этот диапазон идентификаторов используется только системными службами и в нем не должно быть обычных пользователей. Однако никто не мешает назначить службе UID выше 1000, а пользователю менее 999, но никаких последствий это иметь не будет и никак не скажется на привилегиях. Это разделение чисто условное и предназначено для повышения удобства администрирования. Встретив в незнакомой системе пользователя с UID до 999, вы будете с большой долей вероятности предполагать, что это служба.

Кроме того, для многих стандартных пользователей идентификаторы зарезервированы, так во всех Debian и основанных на нем дистрибутивах www-data имеет UID и GID — 33, а proxy — 13. Это удобно, скажем вместо:

chown -R www-data:www-data /var/www

chown -R 33:33 /var/www

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

Многое стороннее ПО, например, сервер 1С и сборки PostgresPro занимают ближайшие свободные идентификаторы с верхнего конца диапазона: 999, 998 и т.д.

Из всего изложенного выше вы должны понимать, что система определяет пользователей по идентификаторам, а не по именам, а присвоение идентификаторов регулируется определенными правилами, но никакие из них, кроме двух специальных (0 для root и 65534 для nobody), не дают каких-либо дополнительных прав или привилегий.

Для более гибкого управления пользователями предназначены группы, они позволяют объединять пользователей по любому произвольному принципу и назначать им дополнительные права. Если мы хотим разрешить пользователю повышение прав, то мы включаем его в группу sudo, при этом мы всегда можем легко узнать, кто именно обладает такой возможностью, достаточно посмотреть участников группы.

Посмотреть список групп можно в файле /etc/group

Он имеет следующий формат:

наименование группы:пароль:GID:пользователи группы

Большая часть полей аналогична записям в файле /etc/passwd и мы не будем подробно останавливаться на них. Разберем последний параметр — пользователи группы. При создании пользователя в Linux, если не указано иное, ему автоматически создается основная группа с повторяющим имя названием. Такой пользователь в последнем поле не указывается. Это хорошо видно на скриншоте выше. Но мы можем создать и отдельную группу, которая первоначально не содержит пользователей, и она будет иметь точно такой же вид записи с пустым последним полем.

После того как мы добавим пользователей в группу они будут перечислены в последнем поле через запятую.

Давайте внимательно посмотрим на скриншот и проанализируем членство созданного при установке пользователя andrey в дополнительных группах. Практически все они связанны с доступом к оборудованию или дают возможность использовать некоторые системные механизмы, скажем группа plugdev предоставляет возможность монтировать съемные устройства.

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

Теперь о паролях, как мы уже говорили, современные системы не хранят пароли в открытом виде, а используют для этого хеши — односторонние криптографические функции, при вводе пароля система вычисляет его хеш и сравнивает с уже сохраненным, если хеши совпадают — то пароль введен верно. Такие пароли в Linux называются «затененными» и хранятся в отдельных файлах. Для пользователей это файл /etc/shadow:

Синтаксис этого файла предусматривает девять полей, содержащих следующую информацию:

Имя пользователя
Хеш пароля, если поле содержит ! или *, это означает, что учётная запись заблокирована и этот пользователь не сможет войти в систему.
Дата последней смены пароля — Количество дней, прошедших с 1 января 1970 г.
Число дней, которое должно пройти до смены пароля — Минимальный срок (в днях), который должен пройти, прежде чем пользователь сможет сменить пароль.
Число дней, после которого необходимо сменить пароль — Максимальный срок (в днях), по истечении которого необходимо сменить пароль.
Число дней до предупреждения о необходимости смены пароля — Число дней до истечения срока действия пароля, в течение которых пользователь получает предупреждение об окончании его срока действия.
Число дней до отключения учётной записи — Число дней после окончания срока действия пароля до отключения учётной записи.
Дата отключения учетной записи — Количество дней, прошедших с 1 января 1970 г.
Зарезервированное поле

Наибольший интерес представляет второе поле, содержащее хеш пароля, оно имеет структуру:

$ID$SALT$ENCRYPTED

Где ID — применяемый тип шифрования, могут использоваться следующие значения:

$1 — MD5, самый слабый хеш, в настоящее время не используется
$2 — Blowfish, использовался в BSD-системах
$5 — SHA-256
$6 — SHA-512

В современных системах используется наиболее стойкий хеш SHA-512.

Следующая часть строки — SALT — это соль (модификатор), генерируется случайно для каждого пользователя и используется для увеличения стойкости пароля. Хеш — это односторонняя криптографическая функция, которая позволяет быстро вычислить результат, но сделать обратное преобразование хеша невозможно. Единственный возможный вариант атаки — это подбор. Существуют уже вычисленные значения хеша для наиболее часто используемых сочетаний и словарных слов, т.н. радужные таблицы, с их помощью атака на хеш производится поиском по уже готовой базе.

Соль позволяет исключить атаки при помощи заранее вычисленных значений и при ее случайном значении позволяет скрыть наличие у пользователей одинаковых паролей. На скриншоте выше пользователям ivan и maria были установлены одинаковые пароли, но за счет различной соли они имеют различный хеш.

Ну и наконец ENCRYPTED — это, собственно, хеш. Кроме того, данное поле может содержать спецсимволы: *, ! и !!. Все они обозначают, что учетная запись заблокирована для входа с паролем, но не запрещают иные варианты входа (по SSH-ключу). Символ * обычно используется для системных учетных записей, которым вход в систему запрещен, ! ставится для записей пользователей без пароля или заблокированных администратором (тогда ! ставится перед содержимым поля). Иногда используется символ !!, означающий что данной учетной записи никогда не присваивался пароль (также для такой записи может использоваться просто !).

Для групп используется аналогичный по назначению файл /etc/gshadow

Его структура более проста, а поля имеют следующее назначение:

Имя группы
Хеш пароля, если пароль установлен, не члены группы могут войти в нее, выполнив команду newgrp и указав пароль. Если это поле содержит * или !, ни один пользователь не сможет войти в неё указав пароль.
Администраторы группы — Перечисленные здесь (через запятую) члены группы могут добавлять или удалять членов группы с помощью команды gpasswd.
Члены группы — Здесь перечисляются (через запятую) обычные члены группы, не администраторы.

Поле пароля также может содержать спецсимволы и также как для пользователей символ * используется преимущественно для системных групп, а ! для групп пользователей. По умолчанию пароли групп отсутствуют и вход в них заблокирован, т.е. никто, кроме членов группы, не может войти в группу, а членам пароль не нужен.

Файлы shadow и gshadow содержат важную учетную информацию и должны быть хорошо защищены. Владельцами этих файлов является root:shadow и права доступа для них установлены как 640. Это означает, что вносить изменения в них может только владелец — root, а читать только члены специальной группы shadow. Это дополнительный уровень безопасности, позволяющий исключить доступ к этим файлам добавлением пользователя в группу root (что даст доступ на чтение к другим конфигурационным файлам).

Так как данные о пользователях являются критичными для системы, то указанные выше файлы крайне не рекомендуется изменять вручную, а для управления пользователями и группами следует использовать специальные утилиты, о которых мы поговорим в следующей части. При любом изменении информации в них штатными инструментами система создает резервную копию предыдущей версии файла с добавлением в конце имени символа ~:

passwd
passwd~

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

Дополнительные материалы:

Linux — начинающим. Часть 1. Первое знакомство
Linux — начинающим. Часть 2. Установка Ubuntu Server
Linux — начинающим. Часть 3. Установка Debian 7 для сервера
Linux — начинающим. Часть 4. Работаем с файловой системой. Теория
Linux — начинающим. Часть 4. Работаем с файловой системой. Практика
Linux — начинающим. Часть 5. Управление пакетами в Debian и Ubuntu
Linux — начинающим. Часть 6. Управление пользователями и группами. Теория
Linux — начинающим. Часть 6. Управление пользователями и группами. Практика
Linux — начинающим. Часть 7. Потоки, перенаправление потоков, конвейер
Настройка языка и региональных стандартов в Ubuntu Server/Debian
Используем APT Pinning для закрепления пакетов в Debian и Ubuntu
Linux — начинающим. Что такое Load Average и какую информацию он несет
Обновляем снятый с поддержки дистрибутив Ubuntu
Linux — начинающим. Обновление Debian до следующего выпуска
Осваиваем эффективную работу в Midnight Commander
Linux — начинающим. Что такое пространства подкачки и как они работают
Linux — начинающим. Screen — многозадачность в терминале и ни единого разрыва!
Linux — начинающим. Как узнать температуру процессора и накопителей
Linux — начинающим. Как получить информацию об оборудовании ПК
Linux — начинающим. Установка и первоначальная настройка Debian 11 для сервера

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

What’s the difference between /sbin/nologin and /bin/false

Technically, unless pam is set up to check your shell with pam_shells neither of these can actually prevent your login, if you’re not on the shell. On my system they are even different sizes, so I suspect they actually do something. So what’s the difference? why do they both exist? Why would I use one over the other?

-rwxr-xr-x 1 root root 21K Feb 4 17:01 /bin/false -rwxr-xr-x 1 root root 4.7K Mar 2 14:59 /sbin/nologin

asked Apr 7, 2011 at 20:08
xenoterracide xenoterracide
58.2k 74 74 gold badges 184 184 silver badges 250 250 bronze badges
Sep 12, 2014 at 14:23

I’m curious why /bin/false takes 21k of code to return a «1» return code! (and /sbin/nologin only takes 4.7k)

Feb 5, 2018 at 18:02
useful to read. What is the difference between /sbin/nologin and /bin/false
Sep 4, 2018 at 8:27
Apr 13, 2019 at 2:08

@nxnev Yeah didn’t think about the overhead of ELF. And from my old IBM days there was a program IEFBR14 that was a simple one op-code assembly instruction: BR 14 — Branch to register 14, which would terminate the program with the return code set to whatever was in register 14!

Apr 13, 2019 at 20:45

8 Answers 8

When /sbin/nologin is set as the shell, if user with that shell logs in, they’ll get a polite message saying ‘This account is currently not available.’ This message can be changed with the file /etc/nologin.txt .

/bin/false is just a binary that immediately exits, returning false, when it’s called, so when someone who has false as shell logs in, they’re immediately logged out when false exits. Setting the shell to /bin/true has the same effect of not allowing someone to log in but false is probably used as a convention over true since it’s much better at conveying the concept that person doesn’t have a shell.

Looking at nologin ‘s man page, it says it was created in 4.4 BSD (early 1990s) so it came long after false was created. The use of false as a shell is probably just a convention carried over from the early days of UNIX.

nologin is the more user-friendly option, with a customizable message given to the user trying to log in, so you would theoretically want to use that; but both nologin and false will have the same end result of someone not having a shell and not being able to ssh in.

Доступ пользователей в vsftpd без доступа к shell (/bin/false)

Для обеспечения большей безопасности FTP-сервера VSFTPD (как установить можно почитать тут), запретим пользователям доступ к Shell (/bin/false).

Создание нового пользователя без доступа к Shell (/bin/false):

sudo useradd username -b /home -m -s /bin/false

Где:
username — имя пользователя.
ключ -b — Директория где будет находиться его домашний каталог
ключ -m — Создание домашнего каталога одноименного с названием username.
ключ -s /bin/false — Указываем что пользователю будет отключен Shell

Задаем пароль для созданного пользователя:

sudo passwd username

Если необходимо отключить Shell уже существующему пользователю, то открываем файл /etc/passwd:

sudo nano /etc/passwd

Находим нужного пользователя и меняем /bin/bash на /bin/false. Сохраняем изменения и при следующей авторизации пользователя на FTP будут без доступа к Shell.

По-умолчанию VSFTPD настроен так что доступ к FTP могут получить пользователи у которых включен Shell (т.е. /bin/bash), а пользователи у которых отключен Shell (т.е. /bin/fasle) VSFTPD не смогут авторизоваться на FTP-сервере.

Для того чтобы VSFTPD авторизовал пользователя с отключенным Shell (/bin/fasle) необходимо отредактировать файл /etc/pam.d/vsftpd

sudo nano /etc/pam.d/vsftpd

auth required pam_shells.so

#auth required pam_shells.so

Перезапускаем VSFTPD

sudo service vsftpd restart

Теперь пользователи с отключенным Shell (/bin/fasle), будут успешно авторизоваться на FTP-сервере. А мы в свою очередь получаем дополнительный плюс к безопасности.

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

19. Пользователи

Мы с вами уже не раз обращались к файлу /etc/passwd, наконец-то пришло время разобраться, что же там написано:

cat /etc/passwd

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

И так, что это вообще такое? Думаю все согласятся, что хранить пароли пользователя в открытом виде нельзя, иначе их с лёгкостью узнает любой пользователь с правами суперпользователя. Но система должна знать пароли, чтобы их подтвердить, когда вы логинитесь – поэтому пароли нужно преобразовать в какой-то нечитаемый вид. Но если это сделать так, чтобы можно было преобразовать обратно в читаемый вид – то опять же любой пользователь с правами рута сможет это сделать и получить первоначальный пароль.

Значит пароль нужно так преобразовать, чтобы никак нельзя было узнать первоначальный вид. И когда пользователь введёт пароль, можно будет преобразовать введённый им пароль тем же способом, получить ровно такое же значение, сравнить эти значения, и, если совпадают — пароль подходит. Но даже такой способ недостаточно безопасен – зачастую люди используют стандартные пароли и легко создать базу, где для каждого стандартного пароля будет его хэшированный вид. А потом можно будет попытаться найти в этой базе совпадающий хэш. Если пароль стандартный — это будет довольно просто. Поэтому при хэшировании к паролю ещё добавляют рандомные символы, называемые солью, благодаря чему даже два одинаковых пароля после хэширования будут выглядеть по-разному. Но это всё криптография. Я объяснил очень поверхностно, опуская много деталей, а если кому интересно, можете почитать по ссылке.

Учитывая, что в passwd есть полезная информация о пользователях, скрывать этот файл от всех пользователей как-то нежелательно, но и хранить тут пароли, пусть даже в хэшированном виде, тоже как-то не правильно. Поэтому пароли из /etc/passwd перенесли в другой файл — /etc/shadow, passwd сделали читаемым для всех, а shadow доступен только для рут пользователя.

Пойдём дальше. Третий столбик – уникальный идентификатор пользователя – user id — uid. Очень многое строится именно вокруг uid-а, а не логина пользователя. У root пользователя идентификатор всегда ноль. Обычно для базовых сервисных пользователей uid-ы назначаются ниже 100, для каких-то дополнительных сервисных пользователей – до 999, а с 1000 начинаются uid-ы обычных пользователей.

Дальше идёт идентификатор группы — group id – gid. У каждого пользователя есть одна основная группа. И у каждой группы есть свой уникальный идентификатор. Здесь отображается идентификатор этой основной группы пользователя, для самих групп есть файл /etc/group.

После идентификатора группы идёт небольшой комментарий о пользователе – тут иногда пишут полное имя пользователя, его телефонный номер или какой-то комментарий. Как видите, для некоторых пользователей этот столбец не имеет значения.

Следующий столбец – домашняя директория пользователя. Мы привыкли, что обычно домашняя директория хранится внутри директории /home , но это не обязательно и те же сервисные пользователи используют в качестве домашней директории абсолютно другие пути. У суперпользователя домашняя директория — /root.

Ну и последний столбик – shell – оболочка пользователя. Допустим, у нашего юзера или рута оболочкой выступает bash. Есть ещё другие оболочки – zsh, csh и т.п. — у всех свои преимущества. У сервисных пользователей, как правило, вместо оболочки указан nologin – и если кто-то попытается залогинится этими пользователями — увидит текст о том, что нельзя. И этот текст можно заранее прописать в файле /etc/nologin.txt. В некоторых случаях вместо оболочки можно встретить /bin/false – тоже не позволяет логинится, но работает немного по другому принципу. /bin/false – программа, которая ничего не делает и просто выдаёт ошибку – обычно нужна для каких-нибудь скриптов. И если это указать в /etc/passwd – при логине пользователя с /bin/false он просто получит ошибку и всё.

Зачастую при работе может понадобиться узнать uid пользователя или группы, в которых он состоит – и не обязательно для этого искать нужные строки в /etc/passwd – можно использовать утилиту id:

id id user id user2

Что касается групп — давайте заглянем в /etc/group. Тут синтаксис похож на passwd – тот же разделитель в виде двоеточия, но меньше столбцов. Однако первый столбец – это не имя пользователя, а имя группы. Вы, возможно, заметили, что имена пользователей и групп совпадают. При создании какого-то пользователя по умолчанию создаётся группа с таким же названием – личная группа пользователя (User Private Group – UPG). Это сделано в целях безопасной, но удобной совместной работы с файлами. Станет понятнее, когда пройдём права на файлы.

Дальше у нас x – как и в passwd, речь про пароль, который хранится в хэшированном виде в файле /etc/gshadow. Как и у пользователей, у групп можно поставить пароль с помощью утилиты gpasswd

gpasswd

И потом, с помощью этого пароля, кто-то из другой группы может временно получить права этой группы, используя утилиту newgrp:

newgrp

Но это очень специфичная задача и я пока не видел реальных примеров использования.

Потом у нас идентификатор группы – gid. А в конце – список пользователей в этой группе, через запятую. Пока что у нас тут пусто, только в группе wheel есть пользователь user.

Ну и давайте ещё заглянем в файл /etc/shadow:

sudo cat /etc/shadow

Тут у нас хранится информация о пароле пользователя и всё, что относится к паролю:

пользователь;
пароль в хэшированном виде, причём в начале указывается хэш функция, например, $6$ — это sha512 – то есть каким алгоритмом был хэширован пароль. Также тут вместо пароля может быть * или ! или два восклицательных знака – может зависеть от дистрибутива. Обычно это означает, что аккаунт заблокирован. Как правило, это относится к сервисным или новым аккаунтам, у которых нет паролей.

Дальше у нас идёт информация о том, когда менялся пароль, когда заблокируется и всё такое.

Эту информацию не очень удобно читать из файла – легче использовать утилиту chage:

chage -l user

До этого мы уже создавали пользователя с помощью команды:

useradd user2

Как мы заметили, у пользователей есть много разных настроек, а значит useradd откуда-то взяла настройки по умолчанию. Настройки по умолчанию можно увидеть при помощи ключа -D:

useradd -D

Сразу скажу, что первый параметр – GROUP — будет игнорироваться, для каждого пользователя создаётся его личная группа. Настройки по умолчанию распределены в двух файлах — /etc/default/useradd и /etc/login.defs. Если первый файл – сугубо параметры утилиты useradd, то login.defs содержит параметры для многих утилит, работающих с пользователями и группами.

И так, в файле /etc/default/useradd у нас несколько параметров:

GROUP – если мы не захотим создавать личную группу пользователя, то группа по умолчанию будет группа с gid 100 – это группа users;
HOME – это внутри какой директории создастся домашняя директория пользователя. Т.е мы создаём пользователя user2 и для него создаётся директория user2 внутри директории /home.
INACTIVE – это через сколько дней после устаревания пароля заблокируется аккаунт: -1 – никогда, 0 – сразу же, как устареет пароль, ну или указываете количество дней.
EXPIRE – когда аккаунт заблокируется. Указывается как год, месяц, день (ГГГГ-ММ-ДД).
SHELL – какой интерпретатор будет по умолчанию, в данном случае /bin/bash;

SKEL – путь к шаблонной директории, которая используется при создании пользователя. Тут у нас есть .bash_profile и .bashrc. Если вы хотите, чтобы у всех новых пользователей в домашней директории были какие-то файлы или директории, достаточно положить их в /etc/skel.
CREATE_MAIL_SPOOL – создаёт специальный файл, куда будет попадать входящая почта для пользователя.

Теперь что касается /etc/login.defs:

cat /etc/login.defs

MAIL_DIR – директория, где создастся файл для входящей почты. Вообще тут есть разные варианты, но давайте пока не будем трогать почту.
PASS_MAX_DAYS – максимум дней, разрешённых на один пароль. Скажем, если поставить 30 – нужно будет менять пароль каждый месяц.
PASS_MIN_DAYS – минимум дней, необходимых для смены пароля. Допустим, если поставить 7 – то можно будет менять пароль максимум раз в неделю. Это нужно, если вы хотите защититься от того, чтобы ваши пользователи повторно не использовали старый пароль. Допустим, у вас может стоять политика, чтобы у пользователя пароли не совпадали как минимум с 10 предыдущими паролями. Без минимального времени смены пароля он может просто разом 10 раз ввести новые пароли и потом старый. Так что этот параметр защищает от таких любителей одного пароля.
PASS_MIN_LEN – минимальная длина пароля. Естественно, руту плевать на этот параметр, а вот юзеры должны будут придумать пароль указанной длины.
PASS_WARN_AGE – за сколько дней до устаревания пароля пользователю выйдет предупреждение о том, что ему стоит сменить пароль.
UID_MIN и UID_MAX – минимальный и максимальный uid, который будет выдан пользователю, если конечно вручную не указать другой uid. Максимальное значение примерно 65000.
SYS_UID_MIN и SYS_UID_MAX – uid-ы для сервисных пользователей.
CREATE_HOME – создавать ли домашнюю директорию при создании пользователя.
USERGROUPS_ENAB – тот самый параметр, отвечающий за создание приватной группы пользователя. Без этого параметра группа по умолчанию будет та, что указана в файле /etc/default/useradd.
ENCRYPT_METHOD – SHA512 – алгоритм, по которому хэшируются пароли для /etc/shadow. На самом деле для login.defs есть много других параметров, но пока что нам этого достаточно.

Теперь, зная всё это, давайте рассмотрим утилиту useradd. При простом добавлении:

useradd user3

всё будет ровно с теми параметрами, которые мы рассматривали в файлах useradd и login.defs. Если же мы хотим сделать как-то по своему, то давайте я возьму пару параметров для примера, а остальное вы сами протестируйте.

И так, sudo useradd и ключ -b – base dir – это собственно директория, внутри которой создастся домашняя директория пользователя, как параметр HOME в useradd. Допустим, если я укажу:

sudo useradd user4 -b /home/company/it

то внутри этой директории /home/company/it создастся директория user4. Но нужно заранее создать эту директорию /home/company/it:

mkdir -p /home/company/it

Если у меня уже есть какая-то директория для пользователя и я не хочу её создавать, я могу указать её с ключом -d:

sudo useradd -d /home/olduser user4

Ключ -c – для комментария. Ключ -g основная группа пользователя. Как мы говорили, если этот ключ не указывать, то создастся приватная группа пользователя и она станет основной группой этого пользователя. Если же мы хотим существующую группу – то указываем после ключа -g:

sudo useradd user4 -g groupname

Ключ -G большое – для дополнительных групп. Допустим, если вы хотите, чтобы пользователь кроме основной группы был также в группах wheel и users2:

sudo useradd user4 -g users -G wheel,users2

Вы можете сами задать uid для будущего пользователя:

sudo useradd user4 -u 1111

Теперь посмотрим, что у нас получилось:

sudo useradd user4 -b /home/user/it -с "User Userovich" -g users -G wheel,user2 grep user4 /etc/passwd /etc/group id user4

Как видим, всё так, как мы указывали. Но пока этого не достаточно – пока мы не зададим пароль пользователю, аккаунт будет недоступен.

Для создания пароля используем команду passwd:

sudo passwd user4

Можете также использовать утилиту chage, чтобы настроить времена для пароля:

chage user4

Если вы уже создали пользователя, но хотите изменить какие-то параметры – допустим, поменять комментарий, добавить в группу, переместить домашнюю директорию, поменять uid и т.п. — используйте утилиту usermod. Например, я хочу перенести домашнюю директорию пользователя и добавить его в группу:

sudo usermod user4 -d /var/user4 -m -aG user

Ключ -d указывает на новую домашнюю директорию, но без ключа -m текущая домашняя директория не перенесётся на новое место. Что касается -aG, то G указывает дополнительные группы, но без ключа -a все текущие группы пользователя сбросятся и останется одна группа user.

Чтобы удалить пользователя, используется команда userdel. Но без ключа -r после удаления пользователя останется его домашняя директория, личная группа и почтовый ящик, а с ключом всё это удалится:

sudo userdel -r user2

Что касается групп – всё примерно также – команды:

groupadd groupmod groupdel

Для примера, давайте добавим группу group1:

sudo groupadd group1

У группы можно назначить администратора и пользователей с помощью команды gpasswd:

sudo gpasswd group1 -A user -M user4,root

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

gpasswd -a user group1 gpasswd -d root group1

Чтобы посмотреть, какие группы у пользователя и какие пользователи в группе, можно использовать команду lid:

sudo lid user sudo lid -g group1

Мы много чего разобрали – файлы /etc/passwd и /etc/group, где хранится информация о пользователях и группах, /etc/shadow, где хранится информация о паролях, файлы /etc/default/useradd и /etc/login.defs, где прописаны параметры для новых пользователей, а также различные утилиты для создания новых пользователей и групп, изменения их параметров, паролей и т.п. И хотя мы не стали задерживаться на различных ключах – для вас это практика – создавайте пользователей и группы с различными параметрами, если что не понятно – откройте маны – там многое объясняется. А если какие-то трудности – обращайтесь, вместе разберёмся.