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 първо проверява дали сте собственик, дали съответствате на групата на пътя, или дали попадате в others — което означава всички останали на машината. Едва тогава прилага съответното правило. Ето защо един и същи път може да се държи различно за различни потребители.

Компактната таблица за превод по-долу е достатъчна за останалата част на тази статия:

📝 Забележка: Командите по-долу използват примери, приятелски настроени към Ubuntu, но самият психически модел се прилага в Linux като цяло.

От там първата стъпка става очевидна: преди Мая да може да споделя нещо с екипа, системата трябва да знае, че тя съществува като собствена личност.

Стъпка 1: Създайте лицето в системата

Потребителският акаунт на Linux не е просто етикет в списък. Той дава на Maya идентичност за вход, домашна директория и отделен работен контекст от всички останали на сървъра. Това разделение е това, което прави отчетността възможна. Ако нещо се промени, можете да кажете кой го е променил. Ако достъпът трябва да остане ограничен, можете да го ограничите до един реален акаунт вместо споделен мистериозен вход.

На Ubuntu, удобният за човека начин да създадете този акаунт е:

sudo adduser maya

Ubuntu ще ви преведе през нормалната настройка и обикновено ще създаде /home/maya в същото време. Можете също да видите useradd в скриптове или документация на по-ниско ниво. На системи Debian/Ubuntu, adduser обикновено е по-удобният избор за нормален потребителски акаунт.

Това е също причината споделените акаунти да са такъв лош навик. Ако няколко хора всички се влизат като един и същ потребител — или още по-лошо, “просто използвайте root” — вие губите проследяемостта веднага, и всяко по-късно решение за разрешение става по-небрежно. Потребителският акаунт отговаря кой е Maya. Той все още не отговаря какво споделено пространство на проекта тя може да използва.

Стъпка 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: Съответствие между собственика и работното пространство

Това е липсващото звено зад много начинаещи разочарования. Следващият въпрос е за самото работно пространство: кой го притежава и коя група е прикрепена към него? Докато това не е подравнено, правилното членство на Maya в екипа няма полезно място за прилагане.

За това ръководство използвайте един споделен път и един ограничен път. Споделената екипна зона ще бъде /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, членството на Maya в новата 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 контролът на достъпа става много по-лесен, когато работите по ред вместо да третирате потребители, групи и разрешения като отделни въпроси. В този пример Maya получи точно това, което й трябваше. Тя има реален вход и достъп на екипа до споделеното работно пространство. Тя няма достъп до пътя release-secret.

Използвайте този контролен списък на всеки Ubuntu VPS или малък хостван Linux сървър:

1. Създайте идентичността.
2. Назначете споделения екип.
3. Подравнете собствеността на пътя и групата.
4. Задайте правилото за разрешение за тази работа.
5. Тестирайте както достъпа, така и границите.

Това е преизползваемият контролен списък: идентичност → екип → правило, с подравняване на пътя в средата, така че правилото наистина да има правилното място за прилагане. Ако искате да отидете по-дълбоко следващия път, естествените продължения включват SSH достъп и sudo. Моделите на споделени директории и по-широкото управление на Linux потребители/групи се основават на същата основа. Основната логика не се променя; просто я прилагате в по-специфични ситуации.