Пользователи Linux, группы и разрешения: один практический рабочий процесс адаптации

The Monday-Morning Access Request

В понедельник утром новый член команды присоединяется к вашему проекту и ему нужен доступ к общему рабочему пространству разработки на вашем Ubuntu VPS сегодня. Он должен иметь возможность войти в систему, открыть командный каталог и выполнять обычную работу без ожидания помощи от кого-то еще для каждой небольшой задачи. Он не должен получать доступ root. Он также должен оставаться вне ограниченной области release-secret.

Вот где пользователи Linux, группы и разрешения перестают казаться тремя отдельными темами учебника и начинают действовать как одна практическая система. Может быть, сервер находится на VPS AlexHost, может быть, он находится где-то еще, но вопрос доступа одинаков везде: как дать полезный доступ без предоставления полного контроля?

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

Workflow:
user account → group membership → ownership alignment → permissions → verification

Одна ментальная модель перед любыми командами

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

Три основных вопроса просты:

• Пользователь отвечает: «Кто это?»
• Группа отвечает: «В какой общей команде они находятся?»
• Разрешения отвечают: «Что они могут здесь делать?»

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

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

Компактной таблицы переводов ниже достаточно для остальной части этой статьи:

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

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

Step 1: Create the Person on the System

A Linux user account is not just a label in a list. It gives Maya a login identity, a home directory, and a separate working context from everyone else on the server. That separation is what makes accountability possible. If something changes, you can tell who changed it. If access needs to stay narrow, you can scope it to one real account instead of a shared mystery login.

On Ubuntu, the human-friendly way to create that account is:

sudo adduser maya

Ubuntu will walk you through the normal setup and usually create /home/maya at the same time. You may also see useradd in scripts or lower-level documentation. On Debian/Ubuntu systems, adduser is usually the friendlier choice for a normal human account.

This is also why shared accounts are such a bad habit. If multiple people all log in as the same user — or worse, “just use root” — you lose traceability immediately, and every later permission decision gets sloppier. A user account answers who Maya is. It does not yet answer what shared project space she can use.

Шаг 2: Добавьте их в правильную команду

Теперь Maya существует, но у неё всё ещё нет отношения к общему рабочему пространству. Вот где группы становятся полезными. Основная группа следует за учётной записью по умолчанию. Дополнительные группы — это дополнительные команды, которые вы присоединяете к пользователю, чтобы общий доступ масштабировался чисто по нескольким людям и нескольким проектам.

Если группа вашего проекта ещё не существует, создайте её сначала. Затем добавьте Maya в эту группу вместо замены её существующих дополнительных членств.

⚠️ Предупреждение: usermod -G devteam maya без -a может заменить существующие дополнительные группы Maya. Флаг -a означает «добавить», и это то, что делает это безопасным.

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

sudo groupadd devteam
sudo usermod -aG devteam maya
id maya

Если devteam уже существует, пропустите строку groupadd. В выводе id вы хотите увидеть devteam в списке групп Maya:

Этот вывод доказывает, что членство в команде есть. Это ещё не доказывает, что Maya может использовать рабочее пространство. Нахождение в devteam всё ещё ничего не делает, если сам каталог принадлежит и сгруппирован таким образом, который игнорирует эту команду.

Шаг 3: Сопоставьте владение рабочей области

Это недостающее звено, стоящее за большой частью разочарования начинающих. Следующий вопрос касается самой рабочей области: кто ей владеет и какая группа к ней привязана? До тех пор, пока это не будет согласовано, правильное членство Майи в команде не будет иметь полезного применения.

Для этого пошагового руководства используйте один общий путь и один ограниченный путь. Общая область команды будет /srv/devworkspace. Приватная область будет /srv/release-secrets с одним примером файла внутри. Сначала создайте оба пути:

sudo mkdir -p /srv/devworkspace /srv/release-secrets
sudo touch /srv/release-secrets/deploy-key.txt

Затем проверьте, как эти пути выглядят в настоящий момент:

ls -ld /srv/devworkspace /srv/release-secrets
ls -l /srv/release-secrets/deploy-key.txt

Флаг -d здесь важен, потому что он указывает ls описать саму директорию вместо того, чтобы перечислять её содержимое. В расширенном списке начните с трёх элементов. Сначала посмотрите на строку разрешений слева. Затем проверьте владельца и группу. Если оба пути по-прежнему показывают root root, то новое членство Майи в devteam ещё не имеет полезного подключения.

Если вам нужно было только изменить группу, chgrp devteam /srv/devworkspace сделал бы это. Здесь chown owner:group понятнее, потому что устанавливает полную цель в одной строке. Общая рабочая область должна принадлежать root:devteam, а ограниченный путь должен остаться root:root:

sudo chown root:devteam /srv/devworkspace
sudo chown root:root /srv/release-secrets /srv/release-secrets/deploy-key.txt

После этого выравнивания владения важные части списка должны выглядеть так:

drwxr-xr-x  root devteam  /srv/devworkspace
drwxr-xr-x  root root     /srv/release-secrets
-rw-r--r--  root root     /srv/release-secrets/deploy-key.txt

permissions  owner  group

💡 Совет: Держите ограниченные секреты вне рабочей области с доступом для группы. Это облегчает понимание настройки и избегает беспорядочных граничных случаев записи в директорию, которые не полезны в потоке адаптации начинающих.

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

Шаг 4: Установите разрешения, соответствующие задаче

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

Небольшая матрица ниже — это единственная, которая нужна большинству новичков:

Строка директории — это ловушка. На директории x не означает «запустить папку». Это означает, что вы можете войти в этот путь или пройти через него по дороге к чему-то более глубокому. Вот почему файл может выглядеть читаемым в теории и всё ещё не работать на практике, если вы не можете пересечь путь директории, который к нему ведёт.

Теперь применяйте правила, которые соответствуют этой истории адаптации. Рабочее пространство команды должно быть пригодно для использования root и devteam, но закрыто для всех остальных. Секретная директория должна оставаться только для root, а секретный файл внутри неё должен оставаться читаемым только для root:

sudo chmod 770 /srv/devworkspace
sudo chmod 700 /srv/release-secrets
sudo chmod 600 /srv/release-secrets/deploy-key.txt

Эти цифры проще, чем они выглядят на первый взгляд, когда вы держите их привязанными к задаче. 770 на /srv/devworkspace означает, что root получает полный доступ, а devteam получает такой же общий доступ. Все остальные там ничего не получают. 700 на /srv/release-secrets означает, что только root может даже войти в эту директорию. 600 на deploy-key.txt означает, что только root может читать или изменять файл. Важная часть — не арифметика. Это то, что каждый режим отражает решение, которое вы уже приняли об этом пути.

drwxrwx---  root devteam  /srv/devworkspace
drwx------  root root     /srv/release-secrets
-rw-------  root root     /srv/release-secrets/deploy-key.txt

⚠️ Предупреждение: chmod 777 — это не настоящее исправление. Обычно это означает, что владение или дизайн пути неправильный, поэтому кто-то распыляет широко открытые разрешения поверх ошибки вместо того, чтобы исправить фактический дизайн доступа.

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

Шаг 5: Проверьте доступ и границы

Конфигурация — это только половина работы. Хорошая подготовка Linux также тестирует границу. Условие успеха — не просто «Maya может что-то делать». Это «Maya может выполнять предусмотренную работу и все еще не может пересечь ограниченный путь».

Запустите свежий контекст входа для Maya, затем протестируйте одно разрешённое действие и одно запрещённое действие:

su - maya
cd /srv/devworkspace
touch first-day-check.txt
ls -l /srv/devworkspace

Затем протестируйте границу:

cd /srv/release-secrets
cat /srv/release-secrets/deploy-key.txt

Тест рабочей области должен пройти успешно. Maya должна иметь возможность войти в /srv/devworkspace и создать там простой файл. Тест границы должен завершиться с ошибкой разрешения, и эта ошибка — сигнал успеха. Принцип наименьших привилегий должен иметь границы.

💡 Совет: Если Maya все еще не может использовать /srv/devworkspace, несмотря на то что команды выглядят правильно, откройте свежий сеанс входа и протестируйте снова. Новое членство в дополнительной группе не всегда появляется последовательно в старых оболочках.

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

Распространённые ошибки, которые нарушают модель

Большинство путаницы с разрешениями Linux — это не загадочность Linux. Обычно это происходит из-за одного и того же небольшого набора категориальных ошибок. Иногда пользователь находится в неправильной группе. Иногда неправильно владение путём. Иногда реальная проблема — неправильное предположение о том, что означает x, или использование ярлыка разрешений вместо надлежащего проектирования.

Таблица ниже — практический способ разобраться в этом тумане:

Большинство проблем с разрешениями возникают из-за пропуска слоя и слишком раннего обращения к chmod. Как только вы определите, является ли проблема идентичностью, членством в команде, владением или правилом пути, исправление становится намного более очевидным.

Практический итог

Управление доступом в Linux становится намного проще, когда вы работаете последовательно, вместо того чтобы рассматривать пользователей, группы и разрешения как отдельные вопросы. В этом примере Майя получила ровно то, что ей было нужно. У неё есть реальный логин и доступ команды к общему рабочему пространству. У неё нет доступа к пути release-secret.

Используйте этот контрольный список на любом Ubuntu VPS или небольшом хостинговом Linux-сервере:

1. Создайте идентификацию.
2. Назначьте общую команду.
3. Выровняйте владение путём и группу.
4. Установите правило разрешения для этой задачи.
5. Протестируйте как доступ, так и границы.

Это повторно используемый контрольный список: идентификация → команда → правило, с выравниванием пути в середине, чтобы правило действительно имело правильное место для применения. Если вы хотите углубиться дальше, естественные следующие шаги включают SSH доступ и sudo. Паттерны общих каталогов и более широкое управление пользователями/группами Linux строятся на одном и том же фундаменте. Основная логика не меняется; вы просто применяете её к более конкретным ситуациям.