drwxr-xr-x: що означають дозволи Linux

Що означає drwxr-xr-x

drwxr-xr-x описує каталог, власник якого може змінювати його вміст, а всі інші користувачі можуть читати його та переходити до нього без внесення змін. У вісімковому форматі цей режим має значення 755. Linux виводить ці десять символів на початку кожного рядка результату ls -l. Вони завжди мають однакове значення в однаковому порядку, тому, вивчивши один рядок, ви зрозумієте всі подібні позначення.

Спочатку потрібно врахувати одне правило, оскільки воно визначає, чи дає ваше тестування корисний результат. Користувач root не враховує біти дозволів. Ядро надає root можливість CAP_DAC_OVERRIDE (обхід дискреційного контролю доступу), тому root відкриває файли, режим яких забороняє це іншим користувачам. Кожен приклад на цій сторінці виконується успішно для root, незалежно від значень бітів. Увійдіть як звичайний користувач, якщо хочете спостерігати за роботою цих правил.

Десять символів по одному

Створіть каталог і файл для перевірки. Жодна з цих команд не змінює нічого за межами нового каталогу.

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

За поширеного стандартного значення umask 022 два рядки для каталогів починаються з drwxr-xr-x, а рядок для файлу — з -rw-r--r--.

Перший символ позначає тип файлу, а не дозвіл. d — це каталог. - — звичайний файл. l — символічне посилання. c і b — вузли символьного та блокового пристроїв. s — сокет, а p — іменований канал. Цей символ не входить до вісімкового значення, тому drwxr-xr-x перетворюється на 755, а не на значення, що починається з d.

Наступні дев’ять символів утворюють три групи по три символи. Їхній порядок завжди незмінний.

• Символи 2–4 — тріада власника, тобто біти для користувача, якому належить файл.
• Символи 5–7 — тріада групи, тобто біти для групи файлу.
• Символи 8–10 — тріада інших, тобто біти для всіх інших користувачів.

У тріаді позиції завжди йдуть у такому порядку: r, потім w, потім x. Дефіс означає, що відповідний біт вимкнено. Позиції літер ніколи не змінюються. r-x означає дозвіл на читання без запису. -w- означає дозвіл на запис без читання. Це дозволено, але трапляється рідко.

Отже, drwxr-xr-x розкладається так: d — тип каталогу, потім rwx — власник, r-x — група, а r-x — інші користувачі.

Деякі системи виводять одинадцятий символ. Крапка в кінці, drwxr-xr-x., означає, що файл має контекст SELinux (security enhanced Linux). Дистрибутиви з SELinux, наприклад Fedora і Rocky, зазвичай виводять цей символ. Плюс у кінці, drwxr-xr-x+, означає, що файл має POSIX ACL (access control list), тобто додатковий набір правил поверх цих дев’яти бітів. Перегляньте ці додаткові правила за допомогою getfacl <path>.

r, w і x виконують різні функції для каталогу

Це перше правило, у якому початківці часто помиляються. Літери однакові для файлу й каталогу. Але надані ними права різні.

• r для файлу читає його вміст. r для каталогу дає змогу переглядати назви об’єктів у ньому. Саме це потрібно звичайній команді ls.
• w для файлу змінює його вміст. w для каталогу дає змогу додавати й видаляти записи в ньому. Видалення файлу змінює каталог, тому вирішальним є право на запис до каталогу, а режим самого файлу не має значення.
• x для файлу запускає його як програму. x для каталогу дає змогу проходити через нього, тобто ядро може визначити одне ім’я всередині каталогу під час пошуку шляху.

Саме проходження через каталог часто дивує користувачів. x для каталогу нічого не запускає. Щоб відкрити /srv/site/index.html, потрібне x для /, потім x для /srv, далі x для /srv/site і, нарешті, r для файлу. Якщо в одному з каталогів цього ланцюжка для вас немає x, пошук зупиняється на ньому, а викликачу повертається Permission denied для всього шляху, навіть якщо кінцевий файл доступний для читання всім. namei -l /srv/site/index.html виводить кожен крок ланцюжка разом із його режимом і власником, щоб можна було побачити, на якій ланці пошук зупиняється.

Каталог із r без x — це незвичний проміжний стан, який варто розпізнавати. Звичайний користувач може переглядати назви, оскільки саме це надає r, але не може отримати атрибути жодного об’єкта. Тому ls -l заповнює стовпці розміру та режиму знаками питання і виводить ls: cannot access ...: Permission denied для кожного об’єкта.

Перетворення літер на 755

Кожна трійка — це трьохбітове число. r дорівнює 4, w — 2, x — 1. Додайте значення увімкнених бітів.

• rwx дорівнює 4 + 2 + 1 = 7
• rw- дорівнює 4 + 2 = 6
• r-x дорівнює 4 + 1 = 5
• r-- дорівнює 4
• --- дорівнює 0

drwxr-xr-x дорівнює 7 для власника, 5 для групи та 5 для інших користувачів: 755. -rw-r--r-- — це 6, 4, 4: 644. drwxrwxr-x — це 7, 7, 5: 775, тобто 755 із доданим правом запису для групи. Вам не потрібно рахувати символи вручну, оскільки stat одночасно виводить обидві форми.

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A — це літерна форма, %a — вісімкова, а %U і %G позначають користувача-власника та групу-власника.

Строки прав доступу, які найчастіше шукають

Це режими, з якими ви стикаєтеся на реальному сервері, із вісімковим значенням і прикладами використання.

• -rw-r--r-- — це 644. Звичайні файли, які сервіс лише читає, наприклад файл конфігурації або HTML-сторінка.
• -rw------- — це 600. Секрети: приватний SSH-ключ або файл .env застосунку.
• -rw-rw-r-- — це 664. Файл у каталозі, спільному для групи, де учасникам групи потрібен дозвіл на запис.
• -rwxr-xr-x — це 755. Скрипти й бінарні файли, наприклад /usr/local/bin/backup.sh і більшість /usr/bin.
• -rwx------ — це 700. Приватний скрипт, який може запускати лише його власник.
• drwxr-xr-x — це 755. Майже кожен системний каталог і кореневий каталог документів вебсайту.
• drwx------ — це 700. ~/.ssh і домашні каталоги на сервері з обмеженим доступом.
• drwxrwxr-x — це 775. Каталог, до якого група власника може записувати файли.
• drwxrwsr-x — це 2775. Те саме, але з бітом setgid, тому нові файли всередині успадковують групу каталогу.
• drwxrwxrwt — це 1777. /tmp. Кінцевий t — це sticky bit, тому користувач може видаляти лише власні файли.
• -rwsr-xr-x — це 4755. Бінарний файл setuid, який запускається від імені свого власника, наприклад /usr/bin/passwd і /usr/bin/sudo.
• -rw-rw-rw- — це 666, а drwxrwxrwx — це 777. Доступні для запису всім користувачам. На сервері це майже завжди помилка.
• lrwxrwxrwx показує кожне символічне посилання. Linux ігнорує біти режиму посилання та перевіряє цільовий об’єкт, тому цей рядок не має жодного значення.

Яка тріада застосовується до вас

Ось друге правило, у якому початківці часто помиляються. Ядро вибирає рівно одну тріаду й на цьому зупиняється.

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

З цього випливають дві речі. Тріада власника застосовується навіть тоді, коли вона є найсуворішою. Файл із режимом 0466, який виводиться як -r--rw-rw-, дає своєму власнику лише право на читання, тоді як усі інші можуть записувати, оскільки перевірка власника спрацювала першою, і наступні біти не перевірялися. Це допустимо, але під час першого знайомства з таким випадком він збиває з пантелику.

Тріада групи визначається групою файла, а не списком груп, до яких ви належите. ls -l виводить у кожному рядку два імені: спочатку власника, потім групу. Лише друга група має значення для цього файла. Належність до двадцяти груп допомагає лише тоді, коли файл належить до однієї з них.

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id виводить вашого користувача та всі групи, до яких ви належите. stat виводить власника та групу файла. Порівняйте ці дані, і ви дізнаєтеся, яку тріаду ядро застосує до вас.

Тому спільному каталогу зазвичай призначають групу та біт setgid. sudo chmod 2775 /srv/shared виводиться як drwxrwsr-x, а файли, створені всередині каталогу, успадковують його групу, а не особисту групу автора. Завдяки цьому наступний користувач також може записувати в них. Окремий обліковий запис для кожного сервісу — інша частина цієї схеми. Вона розглядається в матеріалі один користувач Linux на сервіс у VPS.

umask визначає режим кожного нового файла

Новий файл не отримує режим безпосередньо від вас. Він отримує його від програми, яка його створила, за винятком бітів, очищених вашим umask. umask — це маска бітів для видалення, тому що більше значення umask, то приватнішими будуть файли.

Більшість дистрибутивів постачається зі значенням 022. Програма, яка створює звичайний файл, запитує режим 0666. Програма, яка створює каталог, запитує режим 0777. umask очищає 022 в обох запитах, тому для файлів ви отримуєте 644, а для каталогів — 755. Саме цю пару значень зазвичай видно на щойно створеному VPS.

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S виводить те саме значення літерами, і його легше читати, ніж 0022. Установіть umask 027 у ~/.profile, щоб отримати суворіше значення за замовчуванням: 640 для файлів і 750 для каталогів. Тоді ваша група зможе читати вашу роботу, а всі інші — ні.

Важливі два обмеження. umask може лише очищати біти, але не додавати їх. Тому щойно створений файл ніколи не буде виконуваним, незалежно від установленого значення. Крім того, сервіс systemd не читає профіль вашої оболонки, тому значення потрібно встановити безпосередньо у файлі unit.

[Service]
UMask=0027

Чому файли вебсайту мають права 644, а вебкаталоги — 755

Вебсервер працює від власного облікового запису: www-data у Debian і Ubuntu, nginx у Rocky та Alma. Цьому процесу потрібні права на читання файлів, які він обслуговує, і право проходу через батьківські каталоги. Право на запис йому не потрібне, а статичний сайт взагалі не повинен надавати таке право.

Права 644 для файлу надають власнику право на запис, а всім іншим — право на читання. Тому користувач, від імені якого виконується розгортання, може публікувати файли, а користувач вебсервера — обслуговувати запити. Права 755 для каталогу надають власнику право на запис, а всім іншим — право проходу. Тому користувач вебсервера може проходити шляхом, але не може нічого додавати або видаляти. Якщо в застосунку є помилка, він не зможе перезаписати сторінки, які обслуговує.

Правило проходу проявляється саме тут. Якщо сайт розміщено в /home/deploy/site, а /home/deploy має права 750, користувач вебсервера взагалі не може увійти до домашнього каталогу. Запит завершується відповіддю HTTP 403 і таким рядком у /var/log/nginx/error.log:

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

Число 13 — це EACCES, тобто відмова ядра в доступі. З мережею все гаразд: порт прослуховується, а запит надійшов. Саме тому цю проблему важко зрозуміти під час вивчення принципу роботи портів, що прослуховуються, у Linux. Виконайте namei -l /home/deploy/site/index.html і перевірте весь ланцюжок, щоб знайти перший каталог без x для інших користувачів.

Каталог, до якого застосунок записує дані, наприклад каталог для завантажень, є винятком. Надайте доступ через власника, а не через ширші права: sudo chown -R www-data:www-data /srv/site/uploads і залиште режим 755. Право на запис має залишатися лише в каталозі, якому воно потрібне.

chmod без зміни прав для всього дерева

chmod підтримує обидві форми. Вісімкова форма встановлює всі дев’ять бітів одночасно: chmod 644 notes.txt. Символьна форма змінює лише вказані права, а решту залишає без змін: chmod u+x deploy.sh додає право на виконання для власника, а chmod go-w notes.txt вилучає право на запис для групи та інших користувачів.

Рекурсивна зміна прав може пошкодити дерево. chmod -R 755 . позначає виконуваними всі зображення та файли конфігурації, оскільки chmod не відрізняє скрипт від JPEG. Натомість використовуйте велику літеру X.

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

Велика літера X застосовує право на виконання до каталогів і до файлів, у яких це право вже було встановлено для будь-якої категорії користувачів. Для каталогів встановлюється режим 755, для звичайних файлів — 644, а скрипти, які вже були виконуваними, зберігають цей режим. Якщо один файл уже має потрібний режим, chmod --reference=good.sh other.sh копіює його на інші файли.

Повідомлення, які ви бачите, коли щось налаштовано неправильно

bash: ./deploy.sh: Permission denied означає, що у тріаді прав доступу, яка застосовується до вас, для скрипту немає біта x або один із каталогів у його шляху не має x. chmod u+x deploy.sh виправляє перший випадок.

bash: ./deploy.sh: cannot execute: required file not found — це інша помилка з оманливою назвою. Біт x налаштований правильно, але інтерпретатор, указаний у першому рядку, відсутній. Зазвичай причина полягає в закінченнях рядків Windows, тому ядро шукає інтерпретатор з назвою /bin/bash\r. Виправте це за допомогою sed -i 's/\r$//' deploy.sh.

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open. надходить від SSH-клієнта, який відмовляється використовувати приватний ключ, доступний для читання іншим обліковим записам. Для ключа потрібен режим 600, а для ~/.ssh — 700. Повний опис роботи з ключами наведено в розділі керування ключами SSH і правами доступу до їхніх файлів.

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh з’являється в журналі сервера, коли домашній каталог або його .ssh доступний для запису групі. Параметр sshd StrictModes відхиляє ключ, а на стороні клієнта це виглядає як неочікуваний запит пароля без пояснення.

sudo: /etc/sudoers is world writable, а потім sudo: no valid sudoers sources found, quitting означає, що sudo перевірив режим доступу до власного конфігураційного файлу та відмовився запускатися. Цей файл має мати режим 0440. Це типовий наслідок широкої рекурсивної команди chmod. Така помилка може виникнути одночасно з наведеним вище повідомленням sshd, і тоді консоль провайдера залишається єдиним способом відновити доступ.

Чому 777 не є виправленням

Права 777 надають доступ на запис кожному обліковому запису на машині та кожному процесу, що працює від імені будь-якого з цих облікових записів. Сервер запускає служби від імені окремих користувачів, тому «всі» охоплює на VPS набагато більше об’єктів, ніж на ноутбуці. Скомпрометована служба може записувати дані всюди, де дозволено 777.

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

777 майже завжди є неправильною відповіддю на питання про власника. Симптом: «застосунок не може записати в цей каталог». Причина: каталог належить неправильному користувачу. sudo chown -R appuser:appuser /srv/app/storage з режимом 755 вирішує проблему та не дає доступу всім іншим обліковим записам. Створення цих облікових записів до розгортання будь-яких компонентів описано в розділі перші десять хвилин на новому VPS.

Запис для всіх облікових записів доречний в одному відомому місці — /tmp, і записується як drwxrwxrwt. Кінцевий t — це sticky bit: каталог доступний для запису всім, але користувач може видаляти лише файли, власником яких він є. Без цього біта будь-який обліковий запис міг би видалити тимчасові файли іншого облікового запису.

Перевірте режим перед його зміною

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

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002 виводить усе в межах шляху, де встановлено біт запису для всіх користувачів. Це найшвидший спосіб перевірити сервер після того, як хтось виправляв проблеми за допомогою chmod 777.

Щоб перевірити, чи може певний обліковий запис служби увійти до каталогу, виконайте перевірку від імені цього облікового запису. sudo -u www-data test -x /srv/site && echo yes || echo no виводить yes, якщо цей користувач має право проходу до каталогу, і no, якщо такого права немає. Перевірка від імені root нічого не доводить, оскільки root пропускає цю перевірку, і результатом завжди буде yes.

FAQ

Що означає drwxr-xr-x у Linux?

Це каталог, позначений початковим символом d, із режимом 755. Тріада власника — rwx, тому власник має всі дозволи для цього каталогу. Тріада групи — r-x, а тріада інших користувачів — r-x, тому всі інші можуть переглядати імена всередині каталогу та проходити через нього, але лише власник може додавати або видаляти об’єкти. Перевірте будь-який шлях за допомогою stat -c '%A %a %U %G %n' <path>. Команда виводить літерне та вісімкове представлення поруч.

Чому файли вебсервера мають режим 644, а каталоги — 755?

Вебсервер працює від імені іншого облікового запису: www-data в Ubuntu. Йому потрібен дозвіл на читання файлів, які він обслуговує, і дозвіл на проходження через кожен каталог у шляху до них. Дозвіл на запис йому не потрібен. Режим 644 дає власнику дозвіл на запис, а всім іншим — на читання. Режим 755 дає власнику дозвіл на запис, а всім іншим — на проходження. Каталог, до якого застосунок справді має записувати дані, слід передати користувачу цього застосунку за допомогою chown, а не розширювати режим доступу для всіх.

Чи означає біт x, що я можу виконати каталог?

Ні. Для каталогу x означає дозвіл на проходження. Це право розпізнати одне ім’я всередині каталогу, коли ядро проходить шлях. Для цього потрібен cd, як і для кожного відкриття файлу всередині каталогу. Для кожного каталогу в шляху потрібен x. Тому файл із режимом 644 усе одно буде недоступним, якщо у вас немає x для каталогу вище в ієрархії. namei -l /path/to/file виводить режим кожного каталогу в ланцюжку та показує, де припиняється пошук.

Чи може chmod 777 коли-небудь бути правильним виправленням?

На сервері — майже ніколи. Ця команда надає дозвіл на запис кожному обліковому запису на машині, зокрема обліковим записам, від імені яких працюють служби. Тому одна скомпрометована служба може перезаписати файл. Коли застосунок не може записувати до каталогу, справжньою проблемою зазвичай є власник: sudo chown -R appuser:appuser /srv/app/storage із режимом 755 надає застосунку потрібні дозволи та не дозволяє доступ усім іншим. Відомий виняток — /tmp із режимом 1777. Це працює лише тому, що sticky bit не дозволяє користувачам видаляти файли один одного.

Чому ls виводить крапку або плюс після дозволів?

Одинадцятий символ описує правила, що виходять за межі дев’яти бітів дозволів. Крапка, як у drwxr-xr-x., означає, що додано контекст безпеки SELinux. Це нормально для Fedora та Rocky. Плюс, як у drwxr-xr-x+, означає, що встановлено POSIX ACL (список керування доступом), тому певний користувач або група має дозволи, яких не видно в трьох тріадах. Виконайте getfacl <path>, щоб переглянути ці додаткові записи.