Linux користувачі, групи та дозволи: один практичний робочий процес адаптації

The Monday-Morning Access Request

Понеділок вранці, новий член команди приєднується до вашого проекту і потребує доступу до спільного простору розробки на вашому Ubuntu VPS сьогодні. Вони повинні мати можливість увійти, відкрити каталог команди та виконувати звичайну роботу без очікування на когось іншого для кожного малого завдання. Вони не повинні отримувати root доступ. Вони також повинні залишатися подалі від обмеженої області release-secret.

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

Цей посібник слідує одному запиту на адаптацію від початку до кінця, тому кожна команда має чітку роботу та місце в історії. Якщо терміни на кшталт користувач, група та дозвіл коли-небудь здавалися нечіткими самі по собі, це найпростіший спосіб зробити їх зрозумілими.

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

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

Перед будь-якими командами тримайте в голові одну аналогію: думайте про сервер як про офісну будівлю. Користувач — це іменований бейдж для однієї людини. Група — це відділ, до якого вони належать. Дозволи — це правила доступу до кімнат і шаф. Linux стає набагато простішим, коли ви читаєте його таким чином, замість того щоб запам’ятовувати ізольовані команди.

Три основні питання прості:

• Користувач відповідає: «Хто це?»
• Група відповідає: «До якої спільної команди вони належать?»
• Дозволи відповідають: «Що вони можуть робити тут?»

Це також суть принципу найменших привілеїв: дайте комусь рівно стільки доступу, скільки потрібно для роботи, і не більше. Самі по собі дозволи ніколи не вирішують всю проблему, тому що правильне правило на неправильній ідентичності або неправильній команді все одно дає неправильний результат.

Та сама логіка з’являється на кожному файлі та каталозі. Linux спочатку перевіряє, чи ви власник, чи ви відповідаєте групі шляху, чи ви потрапляєте в інші — тобто всі інші на машині. Тільки потім він застосовує відповідне правило. Ось чому один і той же шлях може поводитися по-різному для різних користувачів.

Компактна таблиця перекладу нижче достатня для решти цієї статті:

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

Звідси перший крок стає очевидним: перш ніж Майя зможе поділитися чимось із командою, система повинна знати, що вона існує як окрема людина.

Крок 1: Створіть користувача в системі

Обліковий запис користувача Linux — це не просто мітка в списку. Він дає Майі ідентичність для входу, домашній каталог і окремий контекст роботи від усіх інших на сервері. Це розділення робить можливою відповідальність. Якщо щось змінюється, ви можете сказати, хто це змінив. Якщо доступ повинен залишатися обмеженим, ви можете обмежити його одним реальним обліковим записом замість спільного таємничого входу.

На Ubuntu зручний для людини спосіб створити цей обліковий запис:

sudo adduser maya

Ubuntu проведе вас через звичайне налаштування і зазвичай створить /home/maya одночасно. Ви також можете побачити useradd у скриптах або документації нижчого рівня. На системах Debian/Ubuntu adduser зазвичай є більш зручним вибором для звичайного облікового запису користувача.

Це також причина, чому спільні облікові записи — така погана звичка. Якщо кілька людей входять як один користувач — або гірше, «просто використовують root» — ви негайно втрачаєте можливість відстеження, і кожне подальше рішення щодо дозволів стає менш акуратним. Обліковий запис користувача відповідає на питання, хто така Майя. Він ще не відповідає на питання, який спільний простір проекту вона може використовувати.

Крок 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 будуються на тій же основі. Основна логіка не змінюється; ви просто застосовуєте її до більш конкретних ситуацій.