Блок 8

Пользователи, группы, права доступа

В предыдущем блоке мы столкнулись с ситуацией, когда файл /etc/hosts оказался доступен только для чтения — и обещали вернуться к этому вопросу подробно. Настало время выполнить это обещание. Этот б…

Обновлено: 23 июля 2026 · DeeNet

Введение в блок

В предыдущем блоке мы столкнулись с ситуацией, когда файл /etc/hosts оказался доступен только для чтения — и обещали вернуться к этому вопросу подробно. Настало время выполнить это обещание. Этот блок — один из центральных в курсе: понимание пользователей, групп и прав доступа лежит в основе всей модели безопасности Linux, о которой мы уже неоднократно упоминали, начиная с урока 1.1 (многопользовательская природа UNIX) и урока 3.5 (принцип минимальных привилегий). Здесь мы наконец раскроем эти концепции полностью, на уровне терминала, и научимся уверенно управлять правами доступа, пользователями и группами.

Урок 8.1. Что такое пользователь в Linux и зачем нужна многопользовательская система

Закрепить и углубить понимание многопользовательской природы Linux уже на техническом, а не только концептуальном уровне (частично затронутом в уроке 3.5), подготовив почву для практической работы с пользователями в этом блоке.

Теория

Мы уже знаем из урока 1.1, что Linux унаследовал многопользовательскую архитектуру от UNIX, спроектированную ещё в эпоху, когда к одному большому центральному компьютеру одновременно подключались десятки пользователей через терминалы (в историческом смысле этого слова, вспомните урок 4.1). Хотя сегодня персональные компьютеры чаще всего используются одним конкретным человеком, эта многопользовательская архитектура сохранилась и оказалась чрезвычайно полезной по совершенно другой причине: она обеспечивает разграничение и изоляцию прав — не только между разными людьми, но и между разными программами и системными службами, работающими на одном компьютере.

Каждый пользователь (user) в Linux технически представлен записью в специальном системном файле /etc/passwd (вспомните урок 5.2 — этот файл находится в папке /etc, где хранится подавляющее большинство системных конфигураций; название файла исторически связано со словом «password», хотя сами пароли там уже давно не хранятся напрямую по соображениям безопасности, о чём мы расскажем чуть подробнее в следующем уроке). Каждой учётной записи пользователя присваивается уникальный числовой идентификатор — UID (User ID), который используется системой «под капотом» для всех внутренних операций, связанных с правами доступа, тогда как имя пользователя (username) — это лишь удобное для человека текстовое представление того же самого UID.

Помимо обычных пользователей, которых создают вручную (как мы создавали при установке в Блоке 2, и как тренировались в Блоке 3 через графический интерфейс), в системе также существует множество системных пользователей — специальных учётных записей, создаваемых автоматически самой системой и различными программами при их установке (тему установки программ подробно разберём в Блоке 9), предназначенных не для входа в систему живым человеком, а для запуска определённых служб и процессов от имени отдельной, изолированной, ограниченной в правах учётной записи. Это ещё одно практическое применение принципа минимальных привилегий из урока 3.5: если, например, веб-сервер (Блок 19) работает от имени специального ограниченного системного пользователя, а не от имени администратора системы, потенциальный злоумышленник, нашедший уязвимость именно в веб-сервере, получит куда меньше возможностей навредить системе в целом.

Практика

Шаг 1. Откройте терминал и просмотрите содержимое файла /etc/passwd командой, уже знакомой нам из Блока 5: cat /etc/passwd.

Что вы увидите: длинный список строк, каждая из которых описывает одного пользователя системы, в формате, разделённом двоеточиями (вспомните упражнения с похожим форматом в уроке 6.6, где мы уже тренировались на похожей структуре с файлом people.txt) — например, строка вида student:x:1000:1000:Student:/home/student:/bin/bash.

[Скриншот терминала]

Шаг 2. Найдите свою собственную учётную запись в этом списке, используя уже знакомую нам команду grep из Блока 6: grep student /etc/passwd (подставив своё реальное имя пользователя вместо student, если оно отличается).

Шаг 3. Выведите только список имён всех пользователей системы, комбинируя уже знакомые нам команды из Блока 6: cut -d: -f1 /etc/passwd.

Что вы увидите: длинный список, включающий и вашу личную учётную запись, и множество системных пользователей с техническими именами вроде daemon, www-data, syslog и подобных.

[Скриншот результата]

Шаг 4. Выведите свой собственный UID командой id (мы подробно разберём эту команду в разделе «Разбор команд»): id.

Что вы увидите: строку вида uid=1000(student) gid=1000(student) groups=1000(student),4(adm),24(cdrom)... — ваш числовой идентификатор пользователя, идентификатор основной группы (о группах подробно поговорим в уроке 8.5), и список всех групп, в которые вы включены.

Разбор команд

Команда id

• Назначение:** показывает идентификационную информацию (UID, основную группу, список всех групп) указанного пользователя, либо текущего пользователя, если имя не указано явно.
• Синтаксис:** id [имя_пользователя]
• Реальные примеры использования:** id www-data — проверить UID и группы системного пользователя, от имени которого обычно работает веб-сервер Nginx (тема Блока 19), что может пригодиться при диагностике проблем с правами доступа к файлам сайта.
• Типичные ошибки:** попытка запросить информацию о несуществующем пользователе.

Способы исправления: проверить точное написание имени пользователя, например, сверившись со списком из /etc/passwd (как мы делали на шаге 3 практики).

Возможные ошибки

• Ошибка:** ожидание увидеть настоящие пароли пользователей при просмотре файла /etc/passwd.

Почему возникает: название файла напрямую содержит слово «password», что интуитивно наводит на мысль о хранении паролей именно там.

Как определить: во втором поле каждой строки файла (после первого двоеточия) видна буква x, а не какой-либо зашифрованный пароль.

Как исправить: осознать, что символ x во втором поле означает лишь то, что реальные (зашифрованные) пароли хранятся в отдельном, более защищённом файле /etc/shadow, доступном для чтения только суперпользователю — мы вернёмся к этому файлу подробнее в уроке 8.4.

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

Практические задания

1. Найдите свою учётную запись в /etc/passwd и разберите её на составные части (username, вторая буква x, UID, GID, полное имя/описание, домашняя папка, оболочка по умолчанию), сверяясь с примером из теории урока.
2. Подсчитайте (с помощью уже знакомой команды wc -l из Блока 6), сколько всего учётных записей пользователей существует в вашей системе.
3. Выполните id для своего пользователя и запишите в конспект свой UID и список всех групп, в которые вы включены.

Проверка знаний

Вопрос 1. Что такое UID и зачем он нужен, если у каждого пользователя уже есть удобное текстовое имя?

Ответ: UID (User ID) — уникальный числовой идентификатор пользователя, который система использует «под капотом» для всех внутренних операций, связанных с правами доступа. Текстовое имя пользователя — лишь удобное для человека представление того же самого UID, но система оперирует именно числовым идентификатором.

Вопрос 2. Что означает символ x во втором поле каждой строки файла /etc/passwd?

Ответ: Он означает, что реальный зашифрованный пароль пользователя хранится не в этом файле, а в отдельном, значительно более защищённом файле /etc/shadow, доступном только суперпользователю.

Итоги урока

Вы изучили: понятие пользователя в Linux, UID, назначение файла /etc/passwd, и различие между обычными и системными пользователями.

Вы умеете: просматривать список пользователей системы и получать идентификационную информацию о конкретном пользователе.

В следующем уроке потребуется: это понимание, чтобы разобраться в самом особенном пользователе системы — root.

Урок 8.2. Root и суперпользователь: что это и почему опасно работать под root

Досконально понять роль суперпользователя root — тему, которую мы упоминали множество раз на протяжении курса (уроки 4.3, 2.5, 3.5), но никогда не раскрывали полностью, — и осознать, почему постоянная работа под root считается серьёзной практической ошибкой.

Теория

root — это специальная, встроенная в саму систему учётная запись суперпользователя (superuser), обладающая абсолютно неограниченными правами на любые действия в системе: изменение любых файлов независимо от их владельца и настроенных прав доступа, установку и удаление любого программного обеспечения, управление любыми пользователями и процессами, изменение любых системных настроек. Технически root всегда имеет UID, равный 0 — этот номер зарезервирован именно для суперпользователя во всех без исключения дистрибутивах Linux, в отличие от обычных пользователей, чьи UID обычно начинаются с числа 1000 и выше (вспомните UID своего пользователя из предыдущего урока).

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

Именно поэтому современная практика администрирования Linux (включая используемую нами Ubuntu) построена вокруг механизма sudo — команды, позволяющей временно, точечно выполнить одну конкретную команду с правами root, вместо постоянной работы под этой учётной записью. Подробно синтаксис и настройку sudo разберём в следующем уроке, а здесь важно усвоить сам принцип: сегодня в Ubuntu по умолчанию прямой вход в систему под учётной записью root даже заблокирован (у неё изначально нет установленного пароля для входа) — это осознанное решение разработчиков дистрибутива, продвигающих именно паттерн «обычный пользователь плюс точечное использование sudo» как более безопасную практику по умолчанию.

Также стоит упомянуть, что в приглашении командной строки (вспомните урок 4.3) символ в конце приглашения — $ для обычного пользователя и # для root — служит именно наглядным, постоянно видимым напоминанием о том, под какой учётной записью вы сейчас работаете, что особенно важно в свете только что разобранной темы.

Практика

Практика этого урока — осторожная и наблюдательная, так как мы ещё не разбирали безопасный способ временного получения прав root (это будет в следующем уроке про sudo).

Шаг 1. Проверьте UID пользователя root через уже знакомую нам по предыдущему уроку команду id: id root.

Что вы увидите: строку вида uid=0(root) gid=0(root) groups=0(root)» — обратите внимание, оба идентификатора (UID и основной GID) равны 0`, что подтверждает теорию урока об особом, зарезервированном идентификаторе суперпользователя.

[Скриншот терминала]

Шаг 2. Найдите строку, соответствующую root, в уже знакомом нам файле /etc/passwd (используя grep из Блока 6): grep "^root:" /etc/passwd (обратите внимание на использование символа ^ из урока 6.5 для точного поиска строки, начинающейся именно с «root:», а не любого совпадения этой подстроки где-либо ещё в тексте).

Что вы увидите: строку вида root:x:0:0:root:/root:/bin/bash» — обратите внимание на домашнюю папку /root, о которой мы уже упоминали в уроке 5.2, отдельную от общей папки /home`.

Шаг 3. Попробуйте выполнить команду, требующую административных прав, без каких-либо специальных механизмов повышения прав — например, попытку создать файл в системной защищённой папке: touch /etc/test_file.txt.

Что произойдёт: команда завершится ошибкой доступа (Permission denied, «доступ запрещён») — наглядная демонстрация того, что обычный пользователь по умолчанию действительно ограничен в правах на изменение системных файлов, что мы уже частично наблюдали в предыдущем блоке с файлом /etc/hosts.

Разбор команд

В этом уроке мы не вводим принципиально новых команд, применяя уже знакомую команду id для дополнительной практики. Ключевой инструмент для безопасной, временной работы с правами root — команда sudo — будет подробно разобран в следующем уроке.

Возможные ошибки

• Ошибка:** попытка новичка «упростить себе жизнь», постоянно работая напрямую под root (например, включив постоянный вход под этой учётной записью, если такое в принципе технически возможно на конкретной системе), чтобы избежать повторяющихся запросов подтверждения прав.

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

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

Как исправить: вернуться к рекомендуемой практике — работать под обычным пользователем, используя sudo (следующий урок) только для точечных административных действий.

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

Практические задания

1. Найдите и разберите строку root в файле /etc/passwd, сравнив её структуру со строкой вашего собственного пользователя из предыдущего урока — запишите в конспект, какие поля отличаются, а какие имеют схожий формат.
2. Попробуйте выполнить ещё одну команду, требующую административных прав (например, попытку удалить какой-либо файл внутри /etc — не переживайте, у вас не получится, в этом и смысл задания) и внимательно прочитайте точный текст сообщения об ошибке, запишите его в конспект.
3. Своими словами объясните в конспекте (не подглядывая в теорию), почему принцип «работать под обычным пользователем, используя точечное повышение прав» безопаснее постоянной работы под root.

Проверка знаний

Вопрос 1. Какой UID зарезервирован специально для суперпользователя root во всех дистрибутивах Linux?

Ответ: 0 (ноль).

Вопрос 2. Разрешён ли в Ubuntu по умолчанию прямой вход в систему под учётной записью root?

Ответ: Нет, по умолчанию прямой вход под root заблокирован (у этой учётной записи изначально нет установленного пароля для входа) — это осознанное решение разработчиков, продвигающее использование обычного пользователя с точечным применением `sudo» вместо постоянной работы под root.

Итоги урока

Вы изучили: понятие суперпользователя root, его особый UID, домашнюю папку /root, и принципиальные причины, по которым постоянная работа под root считается небезопасной практикой.

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

В следующем уроке потребуется: это понимание рисков, чтобы освоить безопасный, точечный механизм повышения прав — команду sudo.

Урок 8.3. `sudo`: как работает, файл `/etc/sudoers`

Освоить главный инструмент безопасного администрирования Linux-системы — команду sudo, которая позволяет выполнять отдельные команды с правами root, оставаясь при этом залогиненным под своим обычным, ограниченным пользователем.

Теория

sudo (расшифровывается как «superuser do», «сделать от имени суперпользователя», хотя технически, как мы увидим далее, sudo может использоваться для временного переключения не только на root, но и на любого другого разрешённого пользователя) — это программа, которая позволяет заранее авторизованным пользователям выполнить одну конкретную команду с повышенными правами (по умолчанию — правами root), введя для подтверждения свой собственный пароль (а не пароль root, которого, как мы уже знаем из предыдущего урока, в Ubuntu по умолчанию вообще не существует для прямого входа).

Мы уже неоднократно сталкивались с практическим применением этого механизма в предыдущих блоках, даже не разбирая его подробно: вспомните уроки 2.7 (обновление системы через графический интерфейс запрашивало пароль) и 3.3 (установка программ через App Center тоже запрашивала пароль) — за обоими этими графическими запросами пароля стоял именно механизм, аналогичный sudo.

Синтаксис использования предельно прост: достаточно добавить слово sudo перед любой командой, которая обычно требует административных прав. Например, вспомните ошибку прошлого урока при попытке создать файл в /etc — та же самая команда, выполненная с sudo, сработает успешно: sudo touch /etc/test_file.txt.

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

Кто именно имеет право использовать sudo, и на выполнение каких именно команд — определяется специальным конфигурационным файлом /etc/sudoers. Важная деталь: этот файл настолько критически важен для безопасности системы, что его настоятельно не рекомендуется редактировать напрямую обычными редакторами (nano, vim из Блока 7) — вместо этого существует специальная безопасная команда visudo, которая перед сохранением автоматически проверяет синтаксис файла на корректность, предотвращая ситуацию, когда опечатка в этом критически важном файле могла бы заблокировать вообще всякую возможность администрирования системы (представьте: если файл /etc/sudoers окажется повреждён из-за опечатки, а sudo — единственный способ его исправить, потому что требуются права root, — вы окажетесь в замкнутом круге, из которого крайне сложно выбраться без специальных восстановительных процедур).

На практике, как мы уже знаем из уроков 2.5 и 3.5, первый пользователь, созданный при установке Ubuntu, автоматически включается в специальную группу sudo (о группах подробно поговорим в уроке 8.5), членство в которой как раз и даёт право использовать команду sudo — это гораздо более распространённый на практике способ управления доступом к sudo, чем прямое редактирование файла `/etc/sudoers» для каждого отдельного пользователя.

Практика

Шаг 1. Повторите неудавшуюся в предыдущем уроке команду, но теперь с sudo: sudo touch /etc/test_file.txt.

Что произойдёт: система запросит ваш пароль (введённый текст не будет отображаться на экране никакими символами, даже звёздочками — это стандартное защитное поведение терминала при вводе паролей, отсутствие видимой обратной связи совершенно нормально и не является ошибкой). После правильного ввода пароля и нажатия Enter команда должна выполниться успешно, без ошибки доступа.

[Скриншот терминала]

Шаг 2. Проверьте результат: ls -l /etc/test_file.txt.

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

Шаг 3. Удалите тестовый файл, тоже с sudo, так как для удаления системного файла также потребуются повышенные права: sudo rm /etc/test_file.txt.

Что произойдёт: если прошло меньше отведённого времени (обычно 15 минут) с момента последнего успешного ввода пароля для sudo, повторный запрос пароля не появится — команда должна выполниться сразу.

[Скриншот результата]

Шаг 4. Проверьте, к какой группе относится ваш пользователь, подтверждающей право на использование sudo (вспомните команду id из урока 8.1, где мы уже видели список групп): id | grep sudo (используем уже знакомую нам конструкцию конвейера и grep из Блока 6 для удобного поиска нужного слова в выводе).

Что вы увидите: если ваш пользователь действительно входит в группу sudo (что должно быть так, если вы были первым пользователем, созданным при установке в Блоке 2), в выводе будет присутствовать слово «sudo» среди перечисленных групп.

Важное замечание, не требующее выполнения на этом уроке: для просмотра или редактирования файла /etc/sudoers теоретически используется команда `sudo visudo» — мы намеренно не выполняем реальное редактирование этого файла в рамках практики данного урока, чтобы избежать риска случайного повреждения критически важной конфигурации на раннем этапе обучения; достаточно того, что вы теоретически знаете о существовании этого безопасного инструмента редактирования для будущей самостоятельной работы.

Разбор команд

Команда sudo

• Назначение:** выполняет указанную команду с повышенными правами (по умолчанию — правами root), после подтверждения личности пользователя его собственным паролем.
• Синтаксис:** sudo [опции] команда
• Основные параметры:** -u имя_пользователя (выполнить команду от имени не root, а какого-либо другого конкретного пользователя, если это разрешено настройками /etc/sudoers); -l (list, «показать список» — показать, какие именно команды разрешено выполнять через sudo текущему пользователю согласно настройкам системы).
• Реальные примеры использования:**
• sudo apt update — характерный пример из повседневной практики (подробно команду apt разберём в Блоке 9), обновление списка доступных пакетов требует административных прав.
• sudo systemctl restart nginx — перезапуск системной службы (подробно systemctl разберём в Блоке 10) тоже требует повышенных прав.
• Типичные ошибки:** забыть добавить sudo перед командой, которая требует административных прав, получив в ответ уже знакомое сообщение Permission denied»; либо, наоборот, избыточное, бездумное добавление sudo перед абсолютно каждой командой «на всякий случай», даже когда повышенные права совершенно не требуются (например, sudo ls» для просмотра собственной домашней папки — совершенно излишне и потенциально рискованно, если команда содержит опечатку, способную повлиять на систему сильнее, чем предполагалось).

Как определить: первый случай — явное сообщение об ошибке доступа; второй случай сложнее заметить сразу, это скорее вопрос вырабатываемой со временем интуиции и дисциплины.

Способы исправления: для первого случая — просто повторить команду с добавлением sudo в начале; для второго — сознательно анализировать, действительно ли конкретное действие требует повышенных прав, прежде чем автоматически добавлять `sudo».

Возможные ошибки

• Ошибка:** прямое редактирование файла /etc/sudoers через sudo nano /etc/sudoers (то есть без использования специальной защищённой команды visudo) и допущение синтаксической ошибки в файле.

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

Как определить: после сохранения повреждённого файла последующие попытки использовать sudo» для любых команд, включая попытки исправить сам файл /etc/sudoers`, начинают завершаться ошибками.

Как исправить: это один из немногих сценариев, требующих специальных процедур восстановления системы (например, загрузка в специальном восстановительном режиме) — что выходит за рамки базового материала этого блока, но подчёркивает важность правильного подхода с самого начала.

Как избежать: всегда использовать именно sudo visudo для любого редактирования файла /etc/sudoers», никогда не редактировать этот конкретный файл напрямую через обычные текстовые редакторы, даже с правами sudo».

Практические задания

1. Выполните любую административную команду с sudo (например, повторно создайте и удалите тестовый файл в /etc, как в практике урока) и запишите в конспект точный текст запроса пароля, который вы увидели.
2. Проверьте, входит ли ваш пользователь в группу sudo, используя команду из шага 4 практики этого урока.
3. Своими словами (не подглядывая) объясните в конспекте, почему для редактирования файла /etc/sudoers используется специальная команда visudo, а не просто sudo nano или sudo vim.

Проверка знаний

Вопрос 1. Чей именно пароль запрашивает sudo при первом использовании в сессии — пароль root или пароль текущего обычного пользователя?

Ответ: Пароль текущего обычного пользователя, который выполняет команду через `sudo» — не пароль root, которого, как мы знаем из предыдущего урока, в Ubuntu по умолчанию для прямого входа вообще не существует.

Вопрос 2. Какой специальный инструмент рекомендуется использовать для редактирования файла /etc/sudoers, и почему именно его, а не обычный текстовый редактор?

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

Итоги урока

Вы изучили: принцип работы sudo, роль файла /etc/sudoers, важность специальной команды visudo для его безопасного редактирования.

Вы умеете: выполнять административные команды с временным повышением прав, проверять своё членство в группе sudo.

В следующем уроке потребуется: это понимание механизма повышения прав, чтобы научиться полноценно управлять учётными записями пользователей.

Урок 8.4. Управление пользователями: `useradd`, `usermod`, `userdel`, `passwd`

Освоить полный набор команд для создания, изменения и удаления учётных записей пользователей через терминал — прямой текстовый аналог тех же действий, которые мы уже выполняли через графический интерфейс в уроке 3.5, но теперь с полным контролем и пониманием каждого параметра.

Теория

Все четыре команды этого урока требуют административных прав (`sudo», изученный в предыдущем уроке), так как управление учётными записями других пользователей — это классический пример действия, затрагивающего всю систему в целом, а не только личное пространство текущего пользователя.

useradd — создаёт новую учётную запись пользователя. В отличие от привычного нам по Блоку 3 графического мастера, эта команда по умолчанию выполняет лишь минимальные действия (создаёт запись в /etc/passwd), и для получения полноценно настроенного пользователя (с созданной домашней папкой, установленной оболочкой по умолчанию и так далее) обычно требуются дополнительные параметры, которые мы разберём подробно.

passwd — устанавливает или изменяет пароль пользователя. Важная деталь: реальные пароли, как мы уже знаем из урока 8.1, хранятся не в /etc/passwd, а в отдельном, значительно более защищённом файле /etc/shadow (отсюда и название — «теневой» файл, хранящий чувствительную информацию, скрытую от обычного просмотра), доступном для чтения только суперпользователю root. Именно поэтому даже полный список всех пользователей системы, который вы просматривали в уроке 8.1 через cat /etc/passwd, не давал доступа к реальным паролям — они физически хранятся в другом, куда более защищённом месте.

usermod (user modify, «изменить пользователя») — изменяет параметры уже существующей учётной записи: можно изменить домашнюю папку, оболочку по умолчанию, добавить пользователя в дополнительные группы (подробно о группах — в следующем уроке), заблокировать учётную запись, и многое другое.

userdel (user delete, «удалить пользователя») — удаляет учётную запись пользователя. Важный практический нюанс, о котором стоит помнить: по умолчанию эта команда удаляет только саму учётную запись, но оставляет нетронутой домашнюю папку пользователя со всеми его файлами — для полного удаления, включая домашнюю папку, требуется дополнительный параметр, который мы разберём в разделе «Разбор команд».

Практика

Шаг 1. Создайте новую тестовую учётную запись пользователя с автоматическим созданием домашней папки (параметр -m, от «home directory make»): sudo useradd -m testuser2.

Что произойдёт: система создаст новую учётную запись testuser2» с автоматически созданной домашней папкой /home/testuser2`. Обратите внимание: команда не запросит пароль автоматически — новому пользователю пока попросту не установлен пароль, что мы исправим на следующем шаге.

[Скриншот терминала]

Шаг 2. Установите пароль для нового пользователя: sudo passwd testuser2.

Что произойдёт: система дважды запросит новый пароль (для подтверждения правильности ввода, так как символы не отображаются на экране, как мы уже видели с sudo в предыдущем уроке) — введите любой тестовый пароль дважды одинаково.

Шаг 3. Проверьте, что новый пользователь действительно появился в системе: `grep testuser2 /etc/passwd» (используем уже знакомую нам практику из урока 8.1).

Шаг 4. Проверьте автоматически созданную домашнюю папку: ls -la /home/testuser2 (потребуется sudo, если у вас недостаточно прав на просмотр чужой домашней папки напрямую — но чаще всего простой просмотр списка файлов доступен и без него, в отличие от изменения содержимого).

[Скриншот результата]

Шаг 5. Измените параметры пользователя с помощью usermod» — например, изменим текстовое описание (полное имя) пользователя, используя параметр -c (comment, «комментарий», традиционно используемый для полного имени в этом поле): sudo usermod -c "Тестовый Пользователь Два" testuser2`.

Шаг 6. Проверьте результат изменения: `grep testuser2 /etc/passwd» — обратите внимание на пятое поле (полное имя/описание), которое должно было измениться.

Шаг 7. Удалите тестовую учётную запись вместе с её домашней папкой, используя параметр -r (remove, «удалить» — в данном контексте команды означает именно полное удаление домашней папки вместе с учётной записью): sudo userdel -r testuser2.

Шаг 8. Убедитесь, что и учётная запись, и домашняя папка действительно удалены: grep testuser2 /etc/passwd (не должно быть никакого результата) и ls /home (папки testuser2 больше не должно быть в списке).

Разбор команд

Команда useradd

• Назначение:** создаёт новую учётную запись пользователя.
• Синтаксис:** sudo useradd [опции] имя_пользователя
• Основные параметры:** -m (создать домашнюю папку автоматически); -s путь_к_оболочке (указать оболочку по умолчанию для этого пользователя, например -s /bin/bash»); -c "описание"» (задать полное имя/комментарий); -G группа1,группа2 (сразу включить пользователя в дополнительные группы при создании, подробно о группах — в следующем уроке).
• Реальные примеры использования:** `sudo useradd -m -s /bin/bash -c "Иван Иванов" ivanov» — создать полноценно настроенного пользователя одной командой со всеми основными параметрами сразу.
• Типичные ошибки:** забыть параметр -m, из-за чего у пользователя не будет создана домашняя папка автоматически.

Как определить: при попытке войти под новым пользователем (или проверить его домашнюю папку) обнаруживается, что папки /home/username попросту не существует.

Способы исправления: создать домашнюю папку вручную (уже знакомой нам командой mkdir из Блока 5) и настроить её владельца соответствующим образом (тема следующего урока, про chown), либо удалить пользователя и пересоздать его заново с правильным параметром -m.

Команда passwd

• Назначение:** устанавливает или изменяет пароль пользователя.
• Синтаксис:** passwd [имя_пользователя] (без sudo и без указания имени — изменяет пароль текущего пользователя, для которого не требуются права root, так как пользователь имеет право менять собственный пароль; с sudo и указанием чужого имени — изменяет пароль указанного пользователя от имени администратора).
• Реальные примеры использования:** passwd (без параметров, от имени обычного пользователя) — сменить собственный пароль; sudo passwd имя_другого_пользователя — сбросить пароль другого пользователя, например, если он его забыл.
• Типичные ошибки:** попытка изменить пароль другого пользователя без `sudo».

Способы исправления: добавить sudo перед командой при работе с чужой учётной записью.

Команда usermod

• Назначение:** изменяет параметры уже существующей учётной записи пользователя.
• Синтаксис:** sudo usermod [опции] имя_пользователя
• Основные параметры:** -c "описание"» (изменить комментарий/полное имя); -s путь_к_оболочке (изменить оболочку по умолчанию); -aG группа» (добавить пользователя в дополнительную группу, не удаляя из уже существующих — параметр -a, append, «добавить», здесь критически важен, подробно разберём эту тонкость в следующем уроке); -L (lock, «заблокировать» учётную запись, временно запретив вход без удаления самой записи); -U (unlock, «разблокировать»).
• Реальные примеры использования:** sudo usermod -L ivanov — временно заблокировать учётную запись сотрудника, например, на время его отпуска или расследования инцидента безопасности, не удаляя саму учётную запись и её данные.

Команда userdel

• Назначение:** удаляет учётную запись пользователя.
• Синтаксис:** sudo userdel [опции] имя_пользователя
• Основные параметры:** -r (remove, удалить также домашнюю папку и почтовый ящик пользователя; без этого параметра они остаются на диске).
• Типичные ошибки:** удаление пользователя без параметра -r, когда на самом деле требовалось полное удаление, оставляющее после себя «осиротевшую» домашнюю папку, занимающую место на диске без владельца-пользователя.

Способы исправления: вручную удалить оставшуюся домашнюю папку командой rm -r (с должной осторожностью, вспомните Блок 5), если она действительно больше не нужна.

Возможные ошибки

• Ошибка:** случайное удаление важной учётной записи (например, собственной единственной административной учётной записи) без предварительной уверенности в наличии альтернативного способа входа в систему.

Почему возникает: невнимательность при выборе имени пользователя для команды userdel», особенно при работе с похожими именами (например, testuser и testuser2`, как в нашей практике).

Как определить: невозможность войти в систему под привычной учётной записью после выполнения команды.

Как исправить: если у системы есть хотя бы ещё один пользователь с правами sudo — можно создать новую учётную запись от его имени; если единственная административная учётная запись была удалена без альтернативы — потребуются специальные процедуры восстановления доступа (например, через режим восстановления при загрузке), что выходит за рамки базового материала этого блока.

Как избежать: всегда внимательно перепроверять точное имя пользователя перед выполнением userdel», особенно в системах с похожими именами тестовых и рабочих учётных записей; никогда не удалять единственную учётную запись с правами sudo`, не создав предварительно альтернативный способ административного доступа.

Практические задания

1. Повторите полный цикл этого урока самостоятельно с другим тестовым именем пользователя: создание с -m, установка пароля, изменение параметра через usermod, и удаление с -r.
2. Создайте тестового пользователя без параметра -m и убедитесь, что домашняя папка действительно не создаётся автоматически — исправьте ситуацию, создав папку вручную командой mkdir (как мы уже умеем из Блока 5), а затем удалите тестового пользователя вместе с этой папкой.
3. Заблокируйте (usermod -L) и затем разблокируйте (usermod -U) тестового пользователя, объяснив в конспекте своими словами практическую разницу между блокировкой учётной записи и её полным удалением.

Проверка знаний

Вопрос 1. Где физически хранятся зашифрованные пароли пользователей, и почему не в /etc/passwd?

Ответ: В отдельном, значительно более защищённом файле /etc/shadow, доступном для чтения только суперпользователю root. Разделение сделано специально для повышения безопасности — файл /etc/passwd должен быть доступен для чтения всем пользователям и программам системы для базовых операций, поэтому хранить в нём чувствительные пароли было бы небезопасно.

Вопрос 2. Что произойдёт с домашней папкой пользователя, если удалить его учётную запись командой userdel без параметра -r?

Ответ: Домашняя папка останется на диске нетронутой, «осиротевшей», без связанной с ней активной учётной записи пользователя — для полного удаления, включая домашнюю папку, необходимо явно указать параметр -r.

Итоги урока

Вы изучили: команды useradd, passwd, usermod, userdel для полного управления жизненным циклом учётных записей пользователей.

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

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

Урок 8.5. Группы: `groupadd`, `groups`, `gpasswd`, `/etc/group`

Освоить понятие групп пользователей — механизм, который значительно упрощает управление правами доступа, когда одинаковые права нужно предоставить сразу нескольким пользователям, вместо настройки каждого пользователя по отдельности.

Теория

Группа (group) — это именованное объединение нескольких пользователей, которому, аналогично отдельным пользователям, можно назначать права доступа к файлам и папкам (подробно механизм назначения прав доступа файлам разберём в следующем уроке 8.6). Практическая польза групп становится очевидна в ситуации, когда нужно предоставить одинаковый доступ к определённым ресурсам сразу нескольким пользователям: вместо того чтобы настраивать права для каждого пользователя индивидуально (что становится крайне неудобным и подверженным ошибкам при росте числа пользователей), администратор создаёт одну группу, включает в неё всех нужных пользователей, и настраивает права доступа один раз — сразу для всей группы.

Аналогично пользователям (UID), каждая группа имеет собственный уникальный числовой идентификатор — GID (Group ID), и информация о группах хранится в отдельном системном файле /etc/group, по структуре очень похожем на уже знакомый нам /etc/passwd.

Важное концептуальное различие, о котором стоит явно упомянуть: у каждого пользователя есть ровно одна основная группа (primary group, вспомните вывод команды id из урока 8.1, где мы видели поле gid=) — обычно, в стандартной конфигурации Ubuntu, при создании нового пользователя автоматически создаётся отдельная одноимённая группа, становящаяся его основной группой (например, у пользователя student основной группой по умолчанию будет группа student с тем же самым именем). Помимо основной группы, пользователь может входить в произвольное количество дополнительных групп (secondary/supplementary groups) — именно они и составляют тот самый список из нескольких групп, который мы видели в выводе id в уроке 8.1 (например, groups=1000(student),4(adm),24(cdrom)...).

Именно с этим различием между основной и дополнительными группами связана уже упомянутая в предыдущем уроке важная тонкость параметра usermod -aG — без флага -a (append, «добавить») команда usermod -G» полностью заменяет весь список дополнительных групп пользователя новым указанным списком, что может случайно удалить пользователя из ранее назначенных ему важных групп; с флагом -a` новая группа именно добавляется к уже существующему списку, не затрагивая остальные.

Практика

Шаг 1. Просмотрите список всех групп текущего пользователя простой командой groups» (без аргументов — для текущего пользователя): groups`.

Что вы увидите: список имён всех групп, в которые вы включены — сокращённый, без числовых GID, вариант той же информации, что мы уже видели в более полном выводе `id» в уроке 8.1.

[Скриншот терминала]

Шаг 2. Просмотрите содержимое системного файла /etc/group, аналогично тому, как мы изучали /etc/passwd: cat /etc/group | head -n 10» (используем уже знакомую нам команду head` из Блока 6, чтобы не выводить сразу весь потенциально длинный список).

Что вы увидите: строки формата, разделённого двоеточиями, например sudo:x:27:student» — имя группы, символ-заполнитель (аналогичный x в /etc/passwd`, хотя для групп пароли используются крайне редко на практике), GID, и список пользователей, включённых в эту группу в качестве дополнительной (обратите внимание: пользователи, для которых эта группа является основной, могут не отображаться явно в этом последнем поле — это тонкость, вытекающая из уже упомянутого различия между основной и дополнительными группами).

Шаг 3. Создайте новую тестовую группу: sudo groupadd testgroup.

Шаг 4. Проверьте, что группа появилась в /etc/group: grep testgroup /etc/group.

[Скриншот результата]

Шаг 5. Создайте тестового пользователя (аналогично предыдущему уроку) и добавьте его в новую группу в качестве дополнительной, с обязательным использованием флага -a, о важности которого говорилось в теории: sudo useradd -m testuser3 (создание пользователя), затем sudo usermod -aG testgroup testuser3 (добавление в группу).

Шаг 6. Проверьте результат: groups testuser3 (обратите внимание, в отличие от шага 1, здесь мы указываем имя конкретного другого пользователя явным аргументом, а не оставляем команду без аргументов для проверки текущего пользователя).

Что вы увидите: список групп пользователя testuser3», включающий как его основную группу (по умолчанию testuser3, одноимённую с именем пользователя), так и только что добавленную дополнительную testgroup`.

Шаг 7. Удалите пользователя из группы с помощью команды gpasswd с параметром -d» (delete, «удалить», в данном случае — удалить пользователя именно из указанной группы, а не удалить саму группу или пользователя целиком): sudo gpasswd -d testuser3 testgroup`.

Шаг 8. Удалите тестовую группу и тестового пользователя, чтобы не загромождать систему (используя уже знакомые команды): sudo groupdel testgroup и sudo userdel -r testuser3.

Разбор команд

Команда groupadd

• Назначение:** создаёт новую группу.
• Синтаксис:** sudo groupadd [опции] имя_группы
• Реальные примеры использования:** `sudo groupadd developers» — создать группу для команды разработчиков, которым впоследствии можно будет предоставить общий доступ к определённым файлам проекта (практический пример подобной задачи мы разберём в мини-проекте этого блока).

Команда groups

• Назначение:** показывает список групп, в которые входит указанный (или текущий, если не указан) пользователь.
• Синтаксис:** groups [имя_пользователя]

Команда gpasswd

• Назначение:** несмотря на название, напоминающее о паролях, чаще всего на практике используется именно для управления составом участников группы — добавления и удаления пользователей.
• Синтаксис:** sudo gpasswd [опции] пользователь группа
• Основные параметры:** -a пользователь группа» (add, добавить пользователя в группу — альтернатива уже знакомому usermod -aG); -d пользователь группа» (delete, удалить пользователя именно из указанной группы, оставив его в системе и в остальных группах).
• Типичные ошибки:** перепутать порядок аргументов (пользователь и группа) — команда ожидает сначала имя пользователя, затем имя группы, что может привести к ошибке, если перепутать местами.

Возможные ошибки

• Ошибка:** использование usermod -G» (без флага -a`) для добавления пользователя в новую дополнительную группу, что случайно удаляет его из всех остальных ранее назначенных дополнительных групп.

Почему возникает: невнимательность к разнице между -G и -aG, о которой подробно говорилось в теории.

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

Как исправить: вручную восстановить членство в утраченных группах, добавив их обратно уже с правильным флагом `-a», сверяясь со списком групп, который был у пользователя до ошибочной команды (если он был заранее зафиксирован, например в конспекте или документации системы — ещё один практический аргумент в пользу ведения подобной документации).

Как избежать: всегда использовать именно usermod -aG, а не голый -G, при добавлении пользователя в дополнительную группу, если явно не стоит цель полностью заменить весь список его дополнительных групп.

Практические задания

1. Создайте новую группу, добавьте в неё двух тестовых пользователей (создав их при необходимости), и проверьте результат командой groups для каждого из них.
2. Продемонстрируйте на практике разницу между usermod -G» и usermod -aG: создайте тестового пользователя, добавьте его в первую группу через -aG, затем добавьте во вторую группу через голый -G (без -a) и проверьте командой groups», что пользователь при этом «потерял» членство в первой группе — объясните результат в конспекте.
3. Удалите все созданные в рамках практики этого урока тестовые группы и пользователей, чтобы очистить систему от учебных данных.

Проверка знаний

Вопрос 1. В чём разница между основной группой пользователя и его дополнительными группами?

Ответ: У каждого пользователя есть ровно одна основная группа (обычно, в Ubuntu по умолчанию, одноимённая с именем самого пользователя), и произвольное количество дополнительных групп, в которые он также включён. Оба типа групп могут использоваться для назначения прав доступа, но технически они по-разному хранятся и обрабатываются системой.

Вопрос 2. Что произойдёт, если использовать usermod -G newgroup username» вместо usermod -aG newgroup username`?

Ответ: Список дополнительных групп пользователя будет полностью заменён на новый, состоящий только из newgroup, что приведёт к потере членства во всех ранее назначенных дополнительных группах. Флаг `-a» (append) необходим именно для того, чтобы добавить новую группу, сохранив уже существующие.

Итоги урока

Вы изучили: понятие групп пользователей, GID, разницу между основной и дополнительными группами, файл /etc/group, и команды groupadd, groups, gpasswd.

Вы умеете: создавать группы, добавлять и удалять из них пользователей, корректно используя флаг -a при необходимости.

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

Урок 8.6. Права доступа: чтение/запись/выполнение, владелец/группа/остальные

Разобраться в фундаментальной модели прав доступа Linux — теме, к которой мы подступались множество раз на протяжении курса (символы прав в выводе ls -l» с урока 5.4, ограничения на редактирование /etc/hosts в Блоке 7, ошибки Permission denied» в этом блоке), но никогда не раскрывали полностью.

Теория

Каждый файл и каждая папка в Linux имеет три отдельные категории прав доступа, определяющих, что именно можно с ним делать, и три отдельные категории субъектов, к которым эти права применяются.

Три типа прав:

Чтение (read, обозначается буквой r) — для файла означает право просматривать его содержимое (например, командами cat, less, изученными в Блоке 6); для папки означает право просматривать список файлов внутри неё (командой ls).

Запись (write, обозначается буквой w) — для файла означает право изменять его содержимое; для папки означает право создавать, удалять и переименовывать файлы внутри этой папки (важный нюанс: право на запись в саму папку не то же самое, что право на изменение содержимого файлов внутри неё — это отдельные, независимые права, которые проверяются отдельно в зависимости от конкретного действия).

Выполнение (execute, обозначается буквой x) — для файла означает право запускать его как программу или скрипт (мы вернёмся к этому праву особенно подробно в Блоке 15, при написании собственных Bash-скриптов); для папки это право имеет особое, менее очевидное значение — оно определяет возможность заходить в эту папку (например, командой cd) и обращаться к конкретным файлам внутри неё по имени, даже без права на просмотр общего списка содержимого папки (то есть без права r).

Три категории субъектов:

Владелец (owner, иногда называют user, откуда и берётся буква u в некоторых командах, которую мы увидим в следующем уроке) — конкретный пользователь, которому принадлежит файл (обычно тот, кто его создал, хотя владельца можно и изменить, подробно — в следующем уроке).

Группа (group, буква g) — конкретная группа-владелец файла (мы уже разбирали понятие групп в предыдущем уроке) — права, назначенные для «группы», применяются ко всем пользователям, входящим в эту конкретную группу-владельца (не путать с любыми произвольными группами в системе — именно с той единственной группой, которая назначена данному конкретному файлу).

Остальные (others, буква o) — все прочие пользователи системы, не являющиеся ни владельцем, ни членом группы-владельца.

Теперь вернёмся к уже знакомому нам с урока 5.4 выводу команды ls -l» и разберём его окончательно, во всех деталях. Строка прав доступа состоит из десяти символов, например -rwxr-xr--`:

• Первый символ — тип элемента (- для обычного файла, d» для папки, l» для символической ссылки, как мы уже знаем из уроков 5.4 и 5.7).
• Следующие три символа (rwx в нашем примере) — права владельца: чтение, запись, выполнение.
• Следующие три символа (r-x) — права группы: чтение разрешено, запись запрещена (прочерк - вместо w), выполнение разрешено.
• Последние три символа (r--) — права для остальных: только чтение, ни записи, ни выполнения.

Таким образом, приведённый пример -rwxr-xr-- означает: обычный файл, владелец может читать/изменять/выполнять его, участники группы-владельца могут читать и выполнять, но не изменять, а все остальные пользователи системы могут только читать файл.

Эти же права можно представить и в числовом (восьмеричном) формате, который значительно компактнее и часто используется на практике (мы будем активно применять именно эту нотацию в следующем уроке при работе с командой chmod): каждому из трёх прав (r, w, x) присваивается своё число — чтение равно 4, запись равно 2, выполнение равно 1 — и для каждой из трёх категорий субъектов (владелец, группа, остальные) эти числа складываются. Например, права «чтение+запись+выполнение» (rwx) равны 4+2+1=7; права «только чтение и выполнение» (r-x) равны 4+0+1=5; права «только чтение» (r--) равны 4+0+0=4. Наш пример rwxr-xr-- в числовом формате будет записан как `754» (7 для владельца, 5 для группы, 4 для остальных) — эта компактная числовая запись значительно удобнее для использования в командах, чем перечисление всех девяти буквенных символов по отдельности.

Практика

Шаг 1. Создайте тестовый файл в своей учебной папке (аналогично Блоку 5) и просмотрите его права доступа по умолчанию: touch ~/Linux-Course/Block-08/permissions_test.txt и ls -l ~/Linux-Course/Block-08/permissions_test.txt.

Что вы увидите: типичные права по умолчанию для нового файла, например -rw-rw-r--» — владелец и группа могут читать и изменять, остальные — только читать, и что важно заметить: право на выполнение (x`) по умолчанию отсутствует ни у кого, даже у владельца — это стандартное, безопасное поведение при создании обычного текстового файла.

[Скриншот терминала]

Шаг 2. Переведите увиденные буквенные права в числовой формат самостоятельно, сверяясь с только что изученной теорией — запишите результат (например, для -rw-rw-r-- это должно получиться 664) в конспект, прежде чем двигаться дальше.

Шаг 3. Создайте тестовую папку и сравните права доступа по умолчанию для папки с правами для файла: mkdir ~/Linux-Course/Block-08/test_folder и ls -ld ~/Linux-Course/Block-08/test_folder» (обратите внимание на специальный параметр -d» команды ls, который мы ещё не разбирали подробно, — он показывает информацию именно о самой указанной папке, а не о её содержимом, что было бы стандартным поведением ls без этого параметра).

Что вы увидите: типичные права для новой папки, например drwxrwxr-x — обратите внимание, в отличие от обычного файла, у папки по умолчанию присутствует право на выполнение (x) для всех трёх категорий, что логично, учитывая уже разобранное в теории особое значение этого права именно для папок (возможность заходить внутрь и обращаться к файлам).

[Скриншот результата]

Шаг 4. Проверьте практическое различие между правом чтения (r) и правом выполнения/захода (x) для папки самостоятельно, порассуждав в конспекте: что, по вашему мнению, произойдёт, если у папки будет право x, но не будет права r — сможет ли пользователь перейти в неё командой cd и обратиться к конкретному, заранее известному файлу внутри, но не сможет получить общий список содержимого командой ls? (Мы вернёмся к практической проверке этого рассуждения уже в следующем уроке, когда научимся изменять права доступа командой chmod.)

Разбор команд

В этом уроке мы не вводим новых команд для изменения прав (это будет в следующем уроке с chmod/chown) — используем уже знакомую ls -l» и новый для нас параметр -d`, который стоит разобрать отдельно.

Параметр -d команды ls

• Назначение:** при указании в качестве аргумента папки — показывает информацию именно об этой папке как о самостоятельном элементе, а не о списке её содержимого.
• Реальные примеры использования:** ls -ld /var/log — быстро проверить права доступа к самой папке `/var/log» (Блок 10), не выводя длинный список всех файлов журналов внутри неё.

Возможные ошибки

• Ошибка:** путаница между правом чтения и правом выполнения применительно именно к папкам, где интуиция, основанная на понимании прав для обычных файлов, может ввести в заблуждение.

Почему возникает: для файлов смысл всех трёх прав достаточно интуитивен и прямолинеен, но для папок право x» имеет менее очевидное, специфическое значение (возможность заходить и обращаться к файлам по имени), кардинально отличающееся от смысла того же символа x» применительно к файлу (право запускать файл как программу).

Как определить: непонимание, почему, например, у папки может быть установлено право на выполнение, хотя «выполнить папку» как действие интуитивно не имеет смысла, в отличие от выполнения файла-программы.

Как исправить: запомнить отдельное, специфическое значение права `x» именно для папок — это право на «прохождение через» папку, а не на её «запуск» в привычном понимании.

Как избежать: сознательно разделять в своём понимании смысл каждого из трёх прав отдельно для файлов и отдельно для папок, не считая их значение автоматически идентичным в обоих случаях.

Практические задания

1. Создайте пять разных тестовых файлов и папок, просмотрите их права по умолчанию, и для каждого переведите буквенное представление прав в числовой формат вручную, сверяя результат самостоятельно.
2. Найдите (используя уже знакомую нам команду find из Блока 5, в сочетании с параметром -perm, который мы не разбирали подробно, но можно попробовать через man find, вспомнив урок 4.7) любые файлы в своей домашней папке с правом на выполнение, установленным хотя бы для владельца.
3. Составьте в конспекте таблицу всех восьми возможных комбинаций прав (от 000 до 777 с шагом, соответствующим только «базовым» значениям 0, 1, 2, 3, 4, 5, 6, 7) с расшифровкой каждой в виде буквенных rwx, чтобы закрепить перевод между числовым и буквенным форматом.

Проверка знаний

Вопрос 1. Что означает право на выполнение (x), применённое к папке, в отличие от того же права, применённого к обычному файлу?

Ответ: Для папки право x» означает возможность заходить внутрь неё (например, командой cd) и обращаться к конкретным файлам внутри по имени. Для файла право x» означает возможность запустить его как исполняемую программу или скрипт. Это два принципиально разных по смыслу применения одного и того же символа права.

Вопрос 2. Как перевести буквенное представление прав rw-r--r-- в числовой (восьмеричный) формат?

Ответ: Владелец: rw- = 4+2+0 = 6; группа: r-- = 4+0+0 = 4; остальные: r-- = 4+0+0 = 4. Итоговый числовой формат: 644.

Итоги урока

Вы изучили: три типа прав (чтение, запись, выполнение), три категории субъектов (владелец, группа, остальные), полную структуру строки прав в выводе ls -l, и числовой (восьмеричный) формат записи прав.

Вы умеете: читать и интерпретировать права доступа любого файла или папки, переводить между буквенным и числовым представлением прав.

В следующем уроке потребуется: это фундаментальное понимание модели прав, чтобы научиться практически изменять права доступа командами chmod и владельца файлов командами chown/chgrp.

Урок 8.7. `chmod` (символьный и числовой режим), `chown`, `chgrp`

Освоить практические команды изменения прав доступа и владельцев файлов — прямое практическое применение всей теории предыдущего урока, а также разрешить, наконец, ситуацию с файлом /etc/hosts из Блока 7, доступным только для чтения.

Теория

chmod (change mode, «изменить режим [доступа]») — команда для изменения прав доступа к файлу или папке. Поддерживает два различных способа указания новых прав: числовой (восьмеричный) режим, использующий уже изученную в предыдущем уроке систему чисел от 0 до 7 для каждой из трёх категорий субъектов, и символьный режим, использующий буквенные обозначения и специальные операторы для более точечного, избирательного изменения отдельных прав, не затрагивая остальные.

В символьном режиме используются следующие обозначения субъектов: u (user, владелец), g (group, группа), o (others, остальные), и удобное сокращение a (all, «все три категории сразу»). Операторы изменения: + (добавить указанное право, не затрагивая остальные уже установленные права), - (убрать указанное право), = (установить точно указанный набор прав, полностью заменив предыдущий для данной категории субъектов).

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

chgrp (change group, «изменить группу») — узкоспециализированная команда, изменяющая только группу-владельца файла, не затрагивая владельца-пользователя (хотя, как мы увидим в разборе команд, того же результата можно добиться и через chown с определённым синтаксисом, что делает chgrp во многом вопросом удобства и явности намерения, а не строгой технической необходимости).

Практика

Шаг 1. Вернёмся к нерешённой проблеме из Блока 7. Скопируйте файл /etc/hosts в свою учебную папку (аналогично тому, что мы уже делали в уроке 7.4): `cp /etc/hosts ~/Linux-Course/Block-08/hosts_copy.txt».

Шаг 2. Проверьте права доступа к скопированному файлу: `ls -l ~/Linux-Course/Block-08/hosts_copy.txt».

Что вы увидите: так как копирование через cp без специальных параметров создаёт файл от имени текущего пользователя (то есть вас), права должны позволять полноценное редактирование — в отличие от оригинального /etc/hosts, принадлежащего root.

Шаг 3. Потренируем chmod в числовом режиме. Уберём все права, кроме чтения для владельца: chmod 400 ~/Linux-Course/Block-08/hosts_copy.txt» (числовой формат 400` означает: владелец — только чтение (4), группа — ничего (0), остальные — ничего (0)).

Шаг 4. Проверьте результат: ls -l ~/Linux-Course/Block-08/hosts_copy.txt» — должно получиться -r--------».

[Скриншот терминала]

Шаг 5. Попробуйте открыть файл через nano (изученный в Блоке 7): `nano ~/Linux-Course/Block-08/hosts_copy.txt».

Что произойдёт: вы должны увидеть точно такое же предупреждение «File is read only», какое мы наблюдали в Блоке 7 при попытке отредактировать настоящий /etc/hosts — теперь вы точно понимаете техническую причину этого поведения, а не просто наблюдаете его на практике. Закройте nano (Ctrl+X).

Шаг 6. Верните права на полноценное редактирование, но на этот раз используя символьный режим вместо числового: `chmod u+w ~/Linux-Course/Block-08/hosts_copy.txt» (добавить право записи именно для владельца, не затрагивая остальные уже установленные права).

Шаг 7. Проверьте результат: ls -l ~/Linux-Course/Block-08/hosts_copy.txt» — должно получиться -rw-------».

[Скриншот результата]

Шаг 8. Потренируем chown. Проверьте текущего владельца файла: ls -l ~/Linux-Course/Block-08/hosts_copy.txt» (владельцем должны быть именно вы). Попробуем изменить владельца на root (потребуется sudo, изученный в уроке 8.3): sudo chown root ~/Linux-Course/Block-08/hosts_copy.txt».

Шаг 9. Проверьте результат: `ls -l ~/Linux-Course/Block-08/hosts_copy.txt» — теперь владельцем должен значиться root, хотя файл по-прежнему физически находится в вашей домашней папке.

Шаг 10. Попробуйте отредактировать этот файл снова через nano, уже без `sudo».

Что произойдёт: несмотря на то, что права доступа (chmod) технически всё ещё позволяют владельцу писать в файл (мы устанавливали u+w на шаге 6), теперь владельцем является root, а не вы — поэтому именно ваши личные права как «остальных» (не владельца и не члена группы-владельца, если только группа не совпадает) будут применяться, и, скорее всего, редактирование окажется недоступно. Это наглядная демонстрация того, что права доступа и владелец файла — два независимых, но взаимосвязанных механизма, работающих совместно.

Шаг 11. Верните себе владение файлом обратно (потребуется sudo, так как только root или текущий владелец root может передать владение обратно вам): sudo chown $USER ~/Linux-Course/Block-08/hosts_copy.txt» (здесь мы используем ещё одну полезную встроенную переменную окружения Bash — $USER», автоматически содержащую имя текущего пользователя, аналогично уже изученным нами в Блоке 6 переменным $HOME», $SHELL»).

Разбор команд

Команда chmod

• Назначение:** изменяет права доступа файла или папки.
• Синтаксис (числовой режим):** chmod [опции] число файл
• Синтаксис (символьный режим):** chmod [опции] субъект[+/-/=]право файл
• Основные параметры:** -R» (рекурсивно применить изменение прав ко всем вложенным файлам и папкам, аналогично уже знакомому нам параметру -r» команд cp/rm» из Блока 5, хотя здесь используется именно заглавная -R»).
• Реальные примеры использования:**
• `chmod 755 script.sh» — типичная комбинация прав для исполняемого скрипта (тема Блока 15): владелец может читать/изменять/выполнять, все остальные — только читать и выполнять, но не изменять.
• chmod +x script.sh» — добавить право на выполнение сразу для всех трёх категорий субъектов (сокращённая запись без явного указания a», подразумевающая «для всех», если субъект не указан явно).
• `chmod -R 644 ~/Documents» — рекурсивно установить права «чтение и запись для владельца, только чтение для остальных» для всех файлов внутри папки Documents и её подпапок.
• Типичные ошибки:** установка чрезмерно открытых прав, например `chmod 777» (полный доступ для абсолютно всех, включая запись и выполнение), из соображений «чтобы уж точно заработало», без понимания рисков безопасности такого решения — особенно опасно для файлов, доступных через интернет (тема Блока 14, посвящённого безопасности).

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

Способы исправления: пересмотреть и установить именно минимально необходимые права, следуя уже знакомому нам принципу минимальных привилегий (урок 3.5), вместо избыточно открытых 777.

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

Команда chown

• Назначение:** изменяет владельца файла (а при указании через двоеточие — и группу-владельца одновременно).
• Синтаксис:** sudo chown [опции] новый_владелец[:новая_группа] файл
• Основные параметры:** -R» (рекурсивно, аналогично chmod`).
• Реальные примеры использования:** `sudo chown -R www-data:www-data /var/www/mysite» — характерный пример реальной административной задачи (Блок 19): передать владение всеми файлами сайта специальному системному пользователю, от имени которого работает веб-сервер Nginx, чтобы у него были необходимые права на чтение (а при необходимости и запись) файлов сайта.

Команда chgrp

• Назначение:** изменяет только группу-владельца файла.
• Синтаксис:** sudo chgrp [опции] новая_группа файл
• Реальные примеры использования:** `sudo chgrp developers shared_project/» — передать групповое владение папкой проекта группе разработчиков (созданной, например, в практике урока 8.5), чтобы у всех участников группы появился совместный доступ, определяемый настроенными правами для категории «группа».

Возможные ошибки

• Ошибка:** попытка изменить владельца файла (chown) без `sudo», ожидая, что обычных прав будет достаточно.

Почему возникает: новичок предполагает, что, будучи текущим владельцем файла, он автоматически имеет право «передать» его кому угодно.

Как определить: сообщение об ошибке доступа при попытке выполнить chown без `sudo».

Как исправить: добавить sudo перед командой.

Как избежать: запомнить это правило заранее — изменение владельца файла на другого пользователя, в отличие от изменения прав доступа своего собственного файла (chmod), почти всегда требует прав root.

Практические задания

1. Повторите полный цикл шагов 1–11 практики этого урока самостоятельно на новом тестовом файле, чтобы закрепить понимание взаимодействия chmod и `chown».
2. Создайте тестовый файл и потренируйте символьный режим chmod более разнообразно: добавьте право выполнения только для группы (chmod g+x), затем уберите право чтения для остальных (chmod o-r), проверяя результат командой ls -l после каждого шага.
3. Создайте тестовую папку с несколькими вложенными файлами (используя уже знакомую нам структуру из Блока 5) и примените chmod -R 644 рекурсивно ко всей структуре одной командой — проверьте результат для нескольких файлов на разных уровнях вложенности.

Проверка знаний

Вопрос 1. Чем отличается chmod u+w file.txt от chmod u=w file.txt?

Ответ: u+w добавляет право записи для владельца, не затрагивая остальные уже установленные для него права (например, если было r-x», станет rwx). u=w, наоборот, полностью заменяет права владельца, устанавливая только право записи и убирая любые ранее установленные права чтения или выполнения для владельца (то есть результатом будет именно -w-», а не rwx или что-либо ещё).

Вопрос 2. Почему изменение владельца файла командой chown» обычно требует прав sudo, в отличие от изменения прав доступа своего собственного файла командой chmod`?

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

Итоги урока

Вы изучили: команды chmod (в числовом и символьном режимах), chown, `chgrp» для управления правами доступа и владельцами файлов.

Вы умеете: изменять права доступа и владельцев файлов и папок, понимаете взаимодействие между этими двумя независимыми, но взаимосвязанными механизмами.

В следующем уроке потребуется: это практическое владение основными правами, чтобы познакомиться с более продвинутыми, специальными правами — SUID, SGID и sticky bit.

Урок 8.8. Специальные права: SUID, SGID, sticky bit

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

Теория

Помимо трёх базовых прав (r, w, x) для трёх категорий субъектов, которые мы подробно изучили в предыдущих двух уроках, существует ещё три специальных бита прав, применяемых к исполняемым файлам и папкам в особых ситуациях.

SUID (Set User ID, «установить идентификатор пользователя») — специальный бит, который, будучи установленным на исполняемый файл, заставляет этот файл при запуске выполняться не от имени пользователя, который его запустил, а от имени владельца самого файла. Классический пример использования — команда passwd, которую мы изучали в уроке 8.4: обычный пользователь может изменить свой собственный пароль, хотя реальное изменение требует записи в защищённый файл /etc/shadow, доступный по обычным правам только root — это становится возможным именно благодаря установленному биту SUID на исполняемый файл команды `passwd», временно предоставляющий необходимые повышенные права ровно на время выполнения этой конкретной, строго ограниченной операции.

SGID (Set Group ID, «установить идентификатор группы») — аналогичный механизм, но применительно к группе: исполняемый файл с установленным SGID запускается с правами группы-владельца файла, а не группы пользователя, который его запустил. Дополнительно, будучи применённым не к файлу, а к папке, SGID имеет другое, тоже практически полезное значение: все новые файлы, создаваемые внутри такой папки, автоматически наследуют группу-владельца самой папки, а не основную группу пользователя, который их создал — это удобно для организации общих папок совместной работы (мы применим этот механизм практически в мини-проекте этого блока).

Sticky bit («липкий бит») — специальный бит, применяемый обычно именно к папкам (для отдельных файлов он практически не имеет смысла в современных системах), который ограничивает удаление и переименование файлов внутри такой папки: даже если у пользователя есть право записи в саму папку (что, как мы помним из урока 8.6, обычно означает возможность удалять любые файлы внутри), при установленном sticky bit пользователь может удалить или переименовать только те файлы внутри папки, владельцем которых является он сам (или, разумеется, root). Классический практический пример использования sticky bit — уже знакомая нам папка /tmp (вспомните урок 5.2): она общедоступна для записи всем пользователям системы (чтобы каждый мог создавать свои временные файлы), но благодаря sticky bit один пользователь не может случайно или намеренно удалить временные файлы другого пользователя, даже несмотря на формально общий доступ на запись в саму папку.

В числовом (восьмеричном) формате chmod, эти три специальных бита представляются дополнительной, четвёртой цифрой, добавляемой перед уже знакомыми нам тремя цифрами обычных прав: SUID соответствует числу 4, SGID — числу 2, sticky bit — числу 1 (эта система сложения чисел полностью аналогична уже изученной нами системе для обычных прав r/w/x). В символьном представлении вывода ls -l» эти биты проявляются особым образом, заменяя обычный символ x» на специальные s (для SUID/SGID) или `t» (для sticky bit) в соответствующей позиции.

Практика

Шаг 1. Найдём реальный пример SUID в системе — уже упомянутую в теории команду passwd: ls -l $(which passwd)» (используем уже знакомую команду which» из Блока 5, вложенную внутрь конструкции `$(...)», которая выполняет команду внутри скобок и подставляет её результат — эта конструкция называется «подстановкой команд», command substitution, мы вернёмся к ней подробнее уже в Блоке 15).

Что вы увидите: строку вида -rwsr-xr-x 1 root root ... /usr/bin/passwd» — обратите внимание на букву s» вместо ожидаемой `x» в позиции права на выполнение для владельца — это и есть визуальное проявление установленного бита SUID.

[Скриншот терминала]

Шаг 2. Потренируем sticky bit практически. Создайте тестовую общую папку: mkdir ~/Linux-Course/Block-08/shared_folder» и сделайте её полностью открытой для записи всем: chmod 777 ~/Linux-Course/Block-08/shared_folder».

Шаг 3. Установите sticky bit с помощью числового режима, добавив четвёртую цифру 1 перед уже существующими тремя: `chmod 1777 ~/Linux-Course/Block-08/shared_folder».

Шаг 4. Проверьте результат: ls -ld ~/Linux-Course/Block-08/shared_folder» (вспомните параметр -d» из урока 8.6).

Что вы увидите: строку вида drwxrwxrwt» — обратите внимание на последний символ t» вместо ожидаемого x» в позиции права на выполнение для «остальных» — визуальное проявление установленного sticky bit (буква t» пишется строчными буквами, если право выполнения для этой категории и так было установлено, что соответствует нашему случаю с 777; если бы права выполнения не было, символ отображался бы заглавной T).

[Скриншот результата]

Шаг 5. Потренируем SGID на папке (второе, «папочное» значение этого бита, о котором говорилось в теории). Создайте новую тестовую папку и группу для практики (аналогично уроку 8.5): mkdir ~/Linux-Course/Block-08/team_folder, sudo groupadd testteam», и назначьте группу-владельца этой папке: sudo chgrp testteam ~/Linux-Course/Block-08/team_folder».

Шаг 6. Установите SGID числовым методом (число 2 в качестве четвёртой цифры): `chmod 2775 ~/Linux-Course/Block-08/team_folder».

Шаг 7. Проверьте результат: ls -ld ~/Linux-Course/Block-08/team_folder» — обратите внимание на символ s» в позиции выполнения для группы (аналогично тому, как мы видели s» для владельца в случае с passwd`, но теперь именно в позиции, относящейся к группе).

Шаг 8. Удалите тестовую группу, созданную в рамках практики: `sudo groupdel testteam».

Разбор команд

В этом уроке новых отдельных команд не вводится — мы применяем уже хорошо знакомую команду `chmod» с расширенным, четырёхзначным числовым синтаксисом для установки специальных битов.

Числовой синтаксис chmod для специальных битов

• Назначение:** устанавливает SUID, SGID и/или sticky bit одновременно с обычными правами доступа.
• Синтаксис:** chmod [спец_бит][обычные_права] файл_или_папка, где спец_бит — сумма чисел 4 (SUID) + 2 (SGID) + 1 (sticky bit) в зависимости от того, какие именно биты требуется установить.
• Реальные примеры использования:** chmod 2770 /shared/project» — установить SGID на общую папку проекта (число 2), чтобы все новые файлы внутри автоматически наследовали группу-владельца папки, с правами 770` (полный доступ для владельца и группы, никакого доступа для остальных).
• Типичные ошибки:** установка SUID на файлы, для которых это не является строго обоснованной необходимостью, что создаёт потенциальный риск безопасности — файл с SUID, принадлежащий root, при наличии в нём уязвимости может стать удобным вектором для получения злоумышленником прав root, даже запустив файл от имени обычного, непривилегированного пользователя.

Как определить: сложно определить визуально без целенаправленного аудита системы (тему которого затронем в Блоке 14, посвящённом безопасности).

Способы исправления: пересмотреть необходимость SUID для конкретного файла и убрать этот бит, если он не является строго необходимым для корректной работы системы.

Как избежать: устанавливать SUID только для файлов, где это действительно строго необходимо для корректной работы (как в случае системной команды passwd), и никогда не устанавливать этот бит «на всякий случай» на собственные скрипты или программы без глубокого понимания последствий.

Возможные ошибки

• Ошибка:** путаница между sticky bit и обычными правами записи применительно к общим папкам, приводящая к неверным ожиданиям относительно того, кто именно может удалять файлы.

Почему возникает: до знакомства с материалом этого урока новичок мог считать, что «право на запись в папку = право удалить любой файл внутри неё», без исключений — что верно только при отсутствии sticky bit.

Как определить: неожиданное поведение при попытке удалить чужой файл в общей папке с установленным sticky bit — операция завершается ошибкой доступа, хотя формальное право записи в саму папку присутствует.

Как исправить: осознать и запомнить особое исключение, которое вносит sticky bit в стандартную логику прав доступа именно для операции удаления/переименования файлов внутри папки.

Как избежать: заранее усвоить материал этого урока и всегда учитывать возможное присутствие sticky bit при анализе прав доступа общих папок, подобных /tmp.

Практические задания

1. Найдите в системе (с помощью find из Блока 5, с параметром -perm -4000, который стоит изучить через man find, вспомнив урок 4.7) другие файлы, помимо passwd, с установленным битом SUID, и запишите в конспект хотя бы два-три найденных примера с кратким предположением об их назначении.
2. Проверьте права папки /tmp командой ls -ld /tmp» и подтвердите, что sticky bit действительно установлен на неё по умолчанию в Ubuntu, сверяясь с признаком t» в конце строки прав, изученным в практике этого урока.
3. Повторите практику установки SGID на папку из шагов 5–7 этого урока самостоятельно, а затем (не удаляя саму папку) создайте внутри неё тестовый файл и проверьте его группу-владельца командой `ls -l» — убедитесь, что она автоматически совпала с группой-владельцем самой родительской папки, а не с вашей личной основной группой, подтверждая практическое действие механизма SGID для папок.

Проверка знаний

Вопрос 1. Что делает бит SUID, установленный на исполняемый файл?

Ответ: Файл при запуске выполняется с правами не того пользователя, который его запустил, а с правами владельца самого файла. Классический пример — команда passwd, позволяющая обычному пользователю изменить свой пароль в защищённом файле `/etc/shadow» благодаря временному повышению прав именно на время выполнения этой команды.

Вопрос 2. Как sticky bit, установленный на общую папку, влияет на возможность удаления файлов внутри неё?

Ответ: Даже при наличии общего права записи в саму папку, пользователь сможет удалить или переименовать только те файлы внутри неё, владельцем которых является он сам (или root), что защищает файлы других пользователей от случайного или намеренного удаления в общих папках, подобных `/tmp».

Итоги урока

Вы изучили: три специальных бита прав — SUID, SGID, sticky bit — их назначение и особенности числового и символьного представления.

Вы умеете: устанавливать специальные биты прав, распознавать их в выводе `ls -l», понимаете практическое применение каждого из них на реальных примерах системы.

В следующем уроке потребуется: весь накопленный материал этого блока о правах доступа, чтобы освоить последнюю тему — расширенные списки доступа ACL, дающие ещё более гибкий контроль, выходящий за рамки классической модели «владелец/группа/остальные».

Урок 8.9. ACL (расширенные списки доступа): `setfacl`, `getfacl`

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

Теория

На протяжении всего блока мы изучали классическую, стандартную модель прав доступа UNIX/Linux: три категории субъектов (владелец, группа, остальные) и три типа прав (чтение, запись, выполнение) для каждой из них. Эта модель проста, эффективна и достаточна для подавляющего большинства практических ситуаций — но у неё есть ограничение: что делать, если требуется предоставить особые, специфические права конкретному дополнительному пользователю (не являющемуся ни владельцем, ни членом группы-владельца) или конкретной дополнительной группе, не создавая при этом новую группу специально под эту единственную задачу и не изменяя общие права для категории «остальные», что затронуло бы вообще всех пользователей системы без разбора?

Именно эту задачу решает ACL (Access Control List, «список контроля доступа») — расширение классической модели прав, позволяющее назначить индивидуальные, точечные права доступа произвольному количеству дополнительных, конкретно указанных пользователей и групп для одного и того же файла или папки, независимо от базовых прав «владелец/группа/остальные».

Два основных инструмента для работы с ACL:

setfacl (set file ACL, «установить ACL файла») — команда для назначения записей ACL.

getfacl (get file ACL, «получить ACL файла») — команда для просмотра уже установленных записей ACL конкретного файла или папки.

Важно понимать: ACL — это дополнение, расширяющее возможности классической модели прав, а не замена ей — базовые права владельца/группы/остальных продолжают действовать и учитываться одновременно с записями ACL, что делает итоговую систему прав доступа файла потенциально более сложной для полного понимания «с первого взгляда» (без явной проверки через getfacl»), поэтому ACL рекомендуется использовать точечно, только когда классической модели прав действительно недостаточно для решения конкретной практической задачи, а не как повсеместную замену привычному chmod».

Практика

Шаг 1. Проверьте, установлена ли поддержка ACL в вашей системе (в современных версиях Ubuntu обычно присутствует по умолчанию): which setfacl» и which getfacl» (используя уже хорошо знакомую нам команду поиска из Блока 5).

Шаг 2. Создайте тестовый файл и посмотрите его текущие права доступа стандартным способом, а также с помощью getfacl, чтобы сравнить оба представления: touch ~/Linux-Course/Block-08/acl_test.txt, затем ls -l ~/Linux-Course/Block-08/acl_test.txt» и getfacl ~/Linux-Course/Block-08/acl_test.txt».

Что вы увидите при выполнении getfacl: более развёрнутое, но концептуально знакомое (владелец/группа/остальные) представление тех же самых базовых прав, что мы уже видели в ls -l, просто в чуть ином, более «расширяемом» формате, специально приспособленном для добавления дополнительных записей ACL.

[Скриншот терминала]

Шаг 3. Создайте тестового пользователя (аналогично предыдущим урокам этого блока), которому предоставим особый, точечный доступ через ACL: `sudo useradd -m acltestuser».

Шаг 4. Назначьте этому конкретному пользователю индивидуальное право на чтение и запись в тестовый файл, не изменяя при этом права владельца, группы или прочих пользователей: setfacl -m u:acltestuser:rw ~/Linux-Course/Block-08/acl_test.txt» (параметр -m», modify, «изменить», указывает на добавление/изменение записи ACL; `u:acltestuser:rw» означает «для конкретного пользователя (u) с именем acltestuser установить права rw»).

Шаг 5. Проверьте результат снова через getfacl»: getfacl ~/Linux-Course/Block-08/acl_test.txt».

Что вы увидите: помимо уже знакомых базовых прав владельца/группы/остальных, появится новая строка вида `user:acltestuser:rw-», явно показывающая индивидуальную запись ACL, назначенную конкретному дополнительному пользователю.

[Скриншот результата]

Шаг 6. Проверьте, что стандартная команда ls -l» тоже отражает наличие дополнительных ACL-записей, хотя и не показывает их детали напрямую: ls -l ~/Linux-Course/Block-08/acl_test.txt».

Что вы увидите: обратите внимание на дополнительный символ +» сразу после стандартной десятисимвольной строки прав (например, -rw-rw-r--+) — это стандартный визуальный признак, сигнализирующий, что у файла есть дополнительные записи ACL, детали которых нужно смотреть именно через getfacl», так как стандартный `ls -l» физически не приспособлен для отображения потенциально произвольного количества индивидуальных ACL-записей.

Шаг 7. Удалите созданную ACL-запись командой с параметром -x (remove, «удалить конкретную запись»): `setfacl -x u:acltestuser ~/Linux-Course/Block-08/acl_test.txt».

Шаг 8. Удалите тестового пользователя, использованного в этой практике: `sudo userdel -r acltestuser».

Разбор команд

Команда setfacl

• Назначение:** устанавливает, изменяет или удаляет записи ACL для файла или папки.
• Синтаксис:** setfacl [опции] правило файл
• Основные параметры:** -m» (modify, добавить или изменить конкретную запись ACL, синтаксис правила: u:имя:права» для пользователя или g:имя:права» для группы); -x» (удалить конкретную запись ACL, без необходимости указывать конкретные права, только субъекта); -R» (рекурсивно применить к папке и всему её содержимому, аналогично уже знакомому нам параметру из chmod/chown); -b» (полностью удалить все записи ACL с файла, вернувшись к чисто классической модели прав).
• Реальные примеры использования:** setfacl -m g:developers:rwx /shared/project» — предоставить группе developers» полный доступ к общей папке проекта, не делая эту группу основной группой-владельцем папки (что могло бы быть неудобно, если у папки уже есть другая, логически более подходящая группа-владелец) и не затрагивая права остальных пользователей системы.
• Типичные ошибки:** забыть, что ACL — это дополнение к базовым правам, а не их полная замена, и удивляться, почему установленные через `chmod» ограничивающие права всё равно как-то влияют на итоговый результат, несмотря на казалось бы более «широкие» права, установленные через ACL для конкретного пользователя.

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

Команда getfacl

• Назначение:** показывает текущие записи ACL (вместе с базовыми правами владельца/группы/остальных) для указанного файла или папки.
• Синтаксис:** getfacl файл
• Реальные примеры использования:** `getfacl /shared/project» — полная диагностика прав доступа сложной общей папки перед внесением дальнейших изменений, чтобы точно понимать текущее состояние всех назначенных прав, включая ACL.

Возможные ошибки

• Ошибка:** чрезмерное усложнение системы прав доступа множеством разрозненных ACL-записей для отдельных пользователей вместо использования более простой и понятной классической модели через группы, там, где это было бы более уместно и управляемо.

Почему возникает: соблазн решать каждую отдельную точечную задачу доступа новой индивидуальной ACL-записью, вместо продумывания более общей, структурированной системы групп (урок 8.5).

Как определить: файл или папка накапливает большое количество разрозненных ACL-записей для множества отдельных пользователей, что становится сложно анализировать и поддерживать в актуальном состоянии со временем, особенно при уходе или смене ролей отдельных сотрудников.

Как исправить: пересмотреть структуру доступа, по возможности заменив множество отдельных пользовательских ACL-записей одной более общей записью для соответствующей логической группы пользователей (вернувшись к принципам урока 8.5).

Как избежать: использовать ACL действительно точечно, для настоящих исключений из общей логики прав, а не как основной, повсеместный инструмент управления доступом — для большинства практических задач продуманная система групп (урок 8.5) в сочетании с классическими правами `chmod» остаётся более простым, понятным и managed-friendly решением.

Практические задания

1. Повторите практику этого урока самостоятельно, но на этот раз назначьте ACL-права не отдельному пользователю, а целой группе (создав тестовую группу, аналогично уроку 8.5, и используя синтаксис g:имя_группы:права» вместо u:имя_пользователя:права»).
2. Проверьте наличие символа +» в выводе ls -l» до и после установки ACL-записи на любой тестовый файл, чтобы наглядно закрепить этот визуальный индикатор.
3. Полностью очистите все ACL-записи с тестового файла командой setfacl -b» и убедитесь через getfacl», что файл вернулся к чисто классической модели прав без каких-либо дополнительных записей.

Проверка знаний

Вопрос 1. Какую задачу решает ACL, которую невозможно (или крайне неудобно) решить классической моделью прав «владелец/группа/остальные»?

Ответ: ACL позволяет назначить индивидуальные, точечные права доступа произвольному конкретному дополнительному пользователю или группе для файла/папки, не создавая специально новую группу под единственную задачу и не затрагивая права категории «остальные» для всех пользователей системы без разбора.

Вопрос 2. Какой визуальный признак в выводе команды ls -l сигнализирует о наличии у файла дополнительных записей ACL?

Ответ: Дополнительный символ +» сразу после стандартной десятисимвольной строки прав доступа (например, -rw-rw-r--+). Сами детали ACL-записей при этом нужно смотреть отдельно, через команду getfacl», так как `ls -l» не показывает их напрямую.

Итоги урока

Вы изучили: концепцию ACL как расширения классической модели прав доступа, команды setfacl и getfacl», визуальный признак наличия ACL в выводе ls -l».

Вы умеете: назначать, просматривать и удалять индивидуальные записи ACL для конкретных пользователей и групп.

В следующем уроке (это будет уже Блок 9) потребуется: полное понимание пользователей, групп и прав доступа, чтобы разобраться в теме установки программ через пакетные менеджеры — процесс, который, как мы уже видели с примером SUID у команды `passwd», тесно связан с правильной настройкой прав на устанавливаемые файлы.

Мини-проект блока

Задача: смоделировать реальную административную задачу — настроить систему с несколькими пользователями, объединёнными в рабочую группу, с общей папкой для совместной работы, применив весь накопленный в этом блоке материал.

Что нужно сделать:

1. Создайте трёх тестовых пользователей (employee1, employee2, employee3), каждого с автоматически создаваемой домашней папкой.
2. Создайте группу project_team и включите в неё всех трёх пользователей в качестве дополнительной группы, используя правильный флаг -a.
3. Создайте общую папку /srv/project_team_folder (вспомните из урока 5.2, что папка /srv» в FHS предназначена для данных сервисов — подходящее, реалистичное место для подобной общей рабочей папки; потребуется sudo` для создания папки вне вашей домашней директории).
4. Назначьте группу-владельца этой папки как project_team, установите права 2770» (обратите внимание на использование SGID из урока 8.8, чтобы все новые файлы внутри автоматически наследовали правильную группу-владельца, и права 770`, дающие полный доступ владельцу и группе, но никакого — остальным).
5. Проверьте результат настройки корректными командами (ls -ld, `getfacl» при желании дополнительно потренировать ACL).
6. Составьте в конспекте итоговый отчёт: что именно вы настроили и зачем, объяснив своими словами роль каждого шага (пользователи, группа, права, SGID).
7. Удалите всех трёх тестовых пользователей, тестовую группу и тестовую папку, чтобы очистить систему после практики.

Критерий готовности: вся настройка выполнена самостоятельно через терминал, без использования графического интерфейса, отчёт написан, тестовые данные удалены.

Контрольные вопросы

1. Объясните, что такое UID и GID, и почему root всегда имеет UID, равный 0.
2. Почему постоянная работа под учётной записью root считается небезопасной практикой? Как эту проблему решает sudo?
3. В чём разница между основной и дополнительными группами пользователя, и почему важен флаг -a в команде usermod -aG?
4. Переведите права доступа rwxr-x--- в числовой формат и объясните, что означает каждая из трёх групп символов.
5. Объясните разницу между chmod и chown, и почему для chown обычно требуется sudo, а для chmod (над собственным файлом) — нет.
6. Что делает бит SUID, и какой классический пример его использования в самой системе Ubuntu вы можете привести?
7. Для какой задачи используется ACL, и чем эта задача принципиально отличается от того, что можно решить классической моделью прав «владелец/группа/остальные»?

Выводы по блоку

Это был один из самых насыщенных и концептуально важных блоков всего курса. Вы прошли путь от базового понимания, что такое пользователь в многопользовательской системе, до полного, практического владения всей моделью безопасности Linux: пользователи и группы, механизм sudo для безопасного администрирования, классические права доступа rwx для владельца/группы/остальных, специальные биты SUID/SGID/sticky bit, и расширенный механизм ACL для точечных исключений. Этот материал — фундамент практически всего дальнейшего администрирования системы, включая настройку служб (Блок 10), веб-серверов (Блок 19) и обеспечение безопасности (Блок 14), где вопросы прав доступа будут возникать регулярно.

Список изученных тем

• Понятие пользователя, UID, файл /etc/passwd, обычные и системные пользователи.
• Суперпользователь root, его особый UID=0, риски постоянной работы под ним.
• Механизм sudo, файл /etc/sudoers», команда visudo`.
• Управление пользователями: useradd, passwd, usermod, userdel», файл /etc/shadow».
• Группы пользователей: groupadd, groups, gpasswd», файл /etc/group», разница основной и дополнительных групп.
• Классическая модель прав доступа: чтение/запись/выполнение для владельца/группы/остальных, числовой и символьный форматы.
• Команды chmod, chown, `chgrp» для изменения прав и владельцев.
• Специальные биты: SUID, SGID, sticky bit.
• Расширенные списки доступа ACL: setfacl, `getfacl».

Рекомендации перед переходом

Прежде чем двигаться дальше, убедитесь, что вы можете уверенно, без подглядывания в конспект, перевести права доступа между буквенным и числовым форматом, объяснить разницу между chmod и chown, и понимаете, зачем нужен принцип минимальных привилегий на практике. Этот материал будет постоянно всплывать в дальнейших блоках курса — при установке программ (Блок 9), настройке служб (Блок 10) и веб-серверов (Блок 19) вы будете регулярно сталкиваться с вопросами «от имени какого пользователя это работает» и «какие права нужны для этого файла», и уверенное владение материалом этого блока сделает работу с этими темами значительно более осмысленной и предсказуемой.