Первые шаги в Linux-правках: права на файлы, umask и безопасное выполнение скриптов

Linux‑права на файлы и каталоги — это одна из тех тем, которые сначала кажутся “сложной матчастью”, а потом внезапно становятся главной причиной, почему скрипт “не работает”. Типичные симптомы знакомы почти всем: Permission denied, Operation not permitted, “файл не исполняется”, “всё работает, но только у меня”, “после копирования права слетели”.

В этой статье соберём практическую шпаргалку: разберём права rwx, владельца и группу, влияние umask, команды chown/chgrp/chmod, а также дадим безопасные шаблоны для запуска bash‑скриптов. Формат — максимально прикладной: так, чтобы можно было открыть материал как памятку и сразу применить.

Права доступа в Linux: rwx, владелец и группа

Три набора прав и три сущности

В классической модели UNIX у каждого файла есть:

• владелец (user, UID)
• группа (group, GID)
• права на доступ трем категориям:
  1. user — владелец файла
  2. group — члены группы
  3. others — все остальные

Права записываются как комбинация r, w, x:

• r (read) — чтение
• w (write) — запись
• x (execute) — выполнение (для скриптов и бинарников) или “доступ в каталог”

Например, строка из ls -l:

-rwxr-x--- 1 alice devops  842 May  1 10:12 deploy.sh

читается так:

• - — тип файла (здесь обычный файл)
• rwx — права владельца alice
• r-x — права группы devops
• --- — правa для остальных

Каталоги: “исполнение” = право прохода

Для каталогов x означает возможность перечисления и/или прохода в зависимости от сочетания с r.

• x на каталог — можно войти (traverse) в каталог
• r на каталог — можно список имён (read directory entries)
• w на каталог — можно создавать/удалять/переименовывать файлы внутри (удаление/создание опирается на права каталога, а не на права самих файлов)

Например:

• rwx на каталог: обычно полные возможности
• r-x: можно зайти и читать содержимое
• -wx: можно зайти и изменять содержимое, но список имён может быть недоступен
• --x: обычно “можно пройти дальше”, но без r список элементов не увидишь

Проверка текущих прав

Быстрые команды:

ls -l
stat file_or_dir
namei -l path   # полезно, чтобы проверить права по каждому компоненту пути

Особенно namei -l пригодится, когда путь состоит из нескольких каталогов, и где-то “закрыто” выполнение (это частая причина Permission denied).

Символьные и числовые права: chmod без магии

Символьная форма

chmod умеет задавать права символами:

• u — user (владелец)
• g — group
• o — others
• a — all
• + добавить право
• - убрать право
• = задать точно

Пример: сделать скрипт исполняемым для всех:

chmod a+x deploy.sh

Ограничить выполнение только владельцем:

chmod u+x deploy.sh
chmod go-x deploy.sh

Задать “как обычно” для исполняемого скрипта: rwxr-x--- (750):

chmod u=rwx,g=rx,o=--- deploy.sh

Числовая форма (octal)

Традиционный способ задавать права — числом (в восьмеричной системе). Биты:

• r = 4
• w = 2
• x = 1

Сумма даёт значение для каждой категории: user, group, others.

Например:

• rwxr-x---:
  • user rwx = 7
  • group r-x = 5
  • others --- = 0
    => 750

Комбинации, которые часто встречаются на практике:

• 644 — обычные файлы конфигураций/документов (rw для владельца, r для всех)
• 640 — секреты/конфиги, доступ группе, но не всем
• 600 — только владельцу (почти всегда private-ключи)
• 700 — исполняемые скрипты, только для владельца
• 750 — исполняемые скрипты, доступ группе, остальным нет
• 755 — исполняемые скрипты для всех (часто допустимо для публичных утилит)

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

stat -c '%a %n' deploy.sh   # например: 750 deploy.sh

chown, chgrp и chmod: что именно делает каждая команда

chmod — права (rwx) и только права

chmod изменяет режим доступа (rwx, плюс специальные биты, если используются).

Примеры:

chmod 750 deploy.sh
chmod u+rw,go-r deploy.sh     # добавить rw владельцу, убрать/ограничить для остальных
chmod -R u+rwX,go-rwxX dir    # аккуратный рекурсивный паттерн (см. ниже)

Подводный камень: chmod -R может затронуть десятки тысяч файлов. Рекурсивные изменения удобны, но легко случайно “переложить” доступ там, где он не нужен (например, в папках с секретами).

chgrp — только группа

chgrp меняет группу файла или директории:

sudo chgrp devops deploy.sh

Полезно, если права уже согласованы, но вы переносите файлы в проект с новой группой.

chown — владелец (и при желании группа)

chown меняет владельца и/или группу:

sudo chown alice deploy.sh
sudo chown alice:devops deploy.sh
sudo chown -R alice:devops project/

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

umask: почему права “не такие”, как вы ожидаете

Что такое umask

umask (user mask) — это маска, которая ограничивает права, с которыми создаются новые файлы/каталоги.

Идея такая: при создании система берёт “базовые” права (обычно для файлов 666 и для каталогов 777), а затем вычитает из них umask. Итоговые права = базовые − umask (в битовом смысле).

Пример: umask 022

• Для файлов: базовое 666, вычитаем 022 => 644
• Для каталогов: базовое 777, вычитаем 022 => 755

Проверка текущего umask

umask

Значение — обычно вроде 0022, 0002, 0077.

Частая проблема: “Я дал права, но новые файлы снова закрыты”

Например, вы настроили chmod на текущий скрипт, но когда создаёте новый файл через touch, редактор или cat > file, права могут получиться неожиданными. Умная логика такая: umask работает на момент создания, а chmod — на существующий объект.

Чтобы проверить, влияют ли текущие настройки:

umask 077
touch testfile
stat -c '%a %n' testfile

Для umask 077 файлы обычно будут 600 (только владелец), и это логично для секретов.

Практический подход: корректный umask для команды/проекта

Для командной разработки часто хотят:

• файлы доступны владельцу и группе (664)
• каталоги доступны владельцу и группе, плюс чтобы можно было создавать внутри (775)

Это достигается umask 002:

• файлы: 666 - 002 = 664
• каталоги: 777 - 002 = 775

Проверка/установка (в текущей сессии):

umask 002

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

Важно: это влияет на новые объекты. Для уже созданных файлов нужно применять chmod/chown.

Безопасное выполнение bash-скриптов: что ломается чаще всего

1) “permission denied” при запуске: чего не хватает

Самое частое: скрипт не имеет x.

Проверка:

ls -l script.sh

Исправление:

chmod u+x script.sh
# или для всех (если уместно):
chmod a+x script.sh

Проверка запуска:

./script.sh

2) Неправильный интерпретатор (shebang)

Если в начале файла не указать корректный интерпретатор, или указан несуществующий путь, скрипт может не исполняться.

Правильный shebang для bash:

#!/usr/bin/env bash

Почему env полезен:

• путь к bash может отличаться в разных системах (/bin/bash, /usr/local/bin/bash, и т.п.)
• в контейнерах/минимальных системах часто удобнее env

Простой способ проверить первую строку:

head -n 1 script.sh

3) Права на директорию, где лежит скрипт

Даже если файл имеет x, но у вас нет x на одну из родительских папок, запуск не пройдёт.

Проверить весь путь:

namei -l ./script.sh

Смотрите, где стоит --- без x.

4) Переносы строк CRLF (часто после Windows)

Если файл подготовлен на Windows, она может добавить \r в конце строк. Тогда shebang станет “не тем”, и вы получите ошибки наподобие “bad interpreter: No such file”.

Проверка по первому символу/строке: иногда проще всего посмотреть:

file script.sh

Если там указано “with CRLF line terminators”, лечим:

sed -i 's/\r$//' script.sh

Безопасные шаблоны bash-скриптов: меньше сюрпризов

Права доступа — только половина истории. “Скрипт не работает” бывает, когда он выполняется с не теми параметрами или в небезопасном окружении. Ниже — практичные паттерны, которые помогают и при дебаге, и при безопасном запуске.

Шаблон “строгого режима” и корректного оболочечного поведения

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

# Пример использования: скрипт ожидает аргументы
: "${1:?Usage: $0 <path>}"

target="$1"
if [[ ! -e "$target" ]]; then
  echo "Target does not exist: $target" >&2
  exit 1
fi

echo "OK: $target"

Что даёт:

• -e: остановка при ошибке
• -u: ошибка при использовании неинициализированных переменных
• pipefail: ошибки в пайплайнах не “теряются”
• корректный IFS, чтобы не ломать обработку пробелов (частая болячка)

Разрешение на запуск “только владельцу” для приватных задач

Если скрипт содержит секреты или работает с ключами:

chmod 700 private_task.sh

И запускать как владелец (или через sudo осмысленно), а не давать 755 “чтобы работало”.

Запуск скрипта через bash script.sh vs ./script.sh

• ./script.sh требует x и правильный shebang.
• bash script.sh использует вашу текущую bash и не требует x (но это не значит “безопасно”: просто исполнение интерпретируется).

Например:

bash deploy.sh

Если вы хотите, чтобы команда была воспроизводимой независимо от прав, этот вариант удобен в CI. Но для “нормальной” эксплуатации — всё-таки лучше дать корректные x и shebang.

Удаление риска “случайно исполняю не тот файл”

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

• фиксировать путь
• проверять, что файл является ожидаемым (например, по размеру/хэшу — в CI)

Простейший контроль:

script_path="./deploy.sh"
if [[ ! -f "$script_path" ]]; then
  echo "Not a file: $script_path" >&2
  exit 1
fi

Практические “рецепты”, которые закрывают 90% проблем

Рецепт 1: “скрипт не исполняется, но права выставлены неправильно”

1. Проверьте x:

stat -c '%a %n' deploy.sh

2. Если это 644 — исправьте:

chmod 755 deploy.sh   # или 750, если остальные не нужны

3. Проверьте shebang:

head -n 1 deploy.sh

Рецепт 2: “после копирования права стали странными”

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

Решение:

sudo chown youruser:yourgroup deploy.sh
chmod 750 deploy.sh

Рецепт 3: “в каталоге права ок, но новые файлы не доступны команде”

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

umask 002
# создайте тестовый файл и проверьте:
touch a && stat -c '%a %n' a

Рецепт 4: рекурсивно привести права проекта (аккуратно!)

Если нужно обновить права во всём дереве, делайте это с пониманием:

• вы хотите оставить исполняемыми только те файлы, которым это нужно
• для каталогов обычно требуется x, чтобы “вход” работал
• для обычных файлов достаточно rw/r

Пример паттерна: сделать так, чтобы каталоги получили rwx для владельца, r-x для группы и --- для others, а обычные файлы — rw для владельца, r-- для группы:

# Для директорий добавим X (execute) по условию: X срабатывает только на каталогах
chmod -R u=rwX,g=rX,o=--- project/

Пояснение:

• X (в отличие от x) применяется только когда объект — каталог или уже имеет x
• это уменьшает риск “сломать” исполняемые/неисполняемые файлы

В реальных проектах такие команды лучше сначала запускать на небольшом поддереве и проверять ls -l и/или find.

Итого: как перестать “лечить права вслепую”

Когда “скрипт не работает из-за прав”, почти всегда можно быстро локализовать причину по цепочке:

1. Есть ли x на файл?
   stat -c '%a %n' file

2. Корректный ли shebang?
   head -n 1 file

3. Есть ли x на родительские директории?
   namei -l ./script.sh

4. Не влияет ли umask на новые файлы?
   umask, затем проверить свежесозданный объект

5. Не сбилась ли владельца/группа?
   ls -l, затем chown/chgrp

И да: чтобы разложить эти механики “по полочкам” и научиться уверенно выполнять типовые операции в консоли, полезно закреплять практикой. В этом смысле курс «Основы работы в консоли Linux, запуск bash скриптов» можно рассматривать как один из вариантов, чтобы системно пройти базу и меньше времени тратить на догадки.

Если хотите, можете принести ваш конкретный вывод команд (ls -l, stat, начало скрипта) — по ним обычно быстро видно, какая именно часть модели прав/интерпретации дала сбой.