Как umask определяет права файлов!

Почему новый файл обычно получает 644, каталог — 755, а один и тот же сервис при разных способах запуска может создавать их с другими правами? За этим стоит umask — маска, которая ограничивает разрешения в момент создания объекта.

umask
umask -S

umask не задаёт итоговые права напрямую. При обычном создании программы часто запрашивают 0666 для файлов и 0777 для каталогов, а маска исключает из запрошенного режима запрещённые биты.

Для чистоты эксперимента удалим объекты, если они остались от предыдущего запуска:

rm -f example.txt
rm -rf example_dir

umask 022

touch example.txt
mkdir example_dir

stat -c '%A %a %n' example.txt example_dir

При 022 запись запрещена для группы и остальных, поэтому получаем 644 для файла и 755 для каталога:

-rw-r--r-- 644 example.txt
drwxr-xr-x 755 example_dir

Популярное объяснение 666 - 022 = 644 удобно для некоторых масок, но технически неверно. Здесь работает побитовая маска:

0666 & ~0022 = 0644
0777 & ~0022 = 0755

И это важно не только теоретически. Например, арифметика ломается уже здесь:

rm -f example.txt

umask 033
touch example.txt

stat -c '%A %a %n' example.txt

Получим:

-rw-r--r-- 644 example.txt

Хотя арифметическое 666 - 033 дало бы 633.

umask может только убрать права, которые запросил процесс, но не добавить отсутствующие. Поэтому даже нулевая маска не сделает обычный файл исполняемым:

rm -f test

umask 000
touch test

stat -c '%A %a %n' test

touch создаёт файл без execute-битов, поэтому результат — 666, а не 777:

-rw-rw-rw- 666 test

Для серверных процессов часто используют более строгий 027: владелец сохраняет запрошенные права, у группы убирается запись, а для остальных запрещаются все права.

rm -f config.txt
rm -rf private_dir

umask 027

touch config.txt
mkdir private_dir

stat -c '%A %a %n' config.txt private_dir

Получаем:

-rw-r----- 640 config.txt
drwxr-x--- 750 private_dir

umask — свойство процесса и наследуется дочерними процессами. Поэтому маска вашего интерактивного shell и процесса, запущенного через systemd, может различаться.

Посмотреть настройку сервиса:

systemctl show nginx -p UMask

Для systemd-сервиса маску можно явно зафиксировать:

[Service]
User=www-data
UMask=0027
ExecStart=/usr/bin/example

После изменения unit-файла перечитываем конфигурацию и перезапускаем сервис:

systemctl daemon-reload
systemctl restart example.service

Но есть нюанс, из-за которого даже при ожидаемом umask можно получить другие права — default ACL родительского каталога.

Если у родительского каталога задан default ACL, при создании объекта umask не используется для обычного расчёта mode & ~umask. Вместо этого новый объект наследует default ACL, а унаследованные разрешения ограничиваются правами, которые запросил создающий процесс.

Проверить ACL:

getfacl /path/to/parent

Поэтому, если сервис создаёт файл не с теми правами, проверять нужно не только значение umask. Важны также mode, который запрашивает сама программа, реальная маска процесса, способ его запуска — shell, systemd, контейнер — и наличие default ACL у родительского каталога. Для диагностики:

umask
getfacl .
stat -c '%A %a %n' example.txt

🔥 umask не назначает права — он ограничивает разрешения, которые процесс запросил при создании объекта. А при наличии default ACL в расчёт вступает механизм наследования ACL.

🚪 Linux Ready | #практика

📂 Напоминалка про переадресацию портов (Port Forwarding)!

Port Forwarding позволяет принимать соединение на одном адресе и порту и перенаправлять трафик на другой — например, с 127.0.0.1:8080 на 172.17.0.3:80.

На картинке показано, чем отличается обычное прямое соединение от переадресации портов, а также два основных подхода: через отдельный процесс в user space и средствами сетевого стека ядра в kernel space.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

GNU mv умеет атомарно менять два файла или каталога местами!

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

У mv теперь есть --exchange:

mv -T --exchange release-new release-current

Если оба пути находятся в одной файловой системе и она поддерживает атомарный обмен, mv меняет их местами одной операцией: release-current становится новым релизом, а прежнее содержимое оказывается в release-new.

Причём это не только для каталогов:

mv --exchange config.new config.conf

Поменять их обратно можно той же командой:

mv --exchange config.new config.conf

Для сценариев, где нельзя допустить незаметного перехода к копированию между файловыми системами, можно добавить --no-copy:

mv -T --exchange --no-copy release-new release-current

🔥 mv --exchange — случай, когда обычная Unix-команда даёт удобный интерфейс к атомарной операции файловой системы, что полезно для переключения релизов, деревьев сборки и быстрого отката без цепочки промежуточных переименований.

🚪 Linux Ready | #совет

📂 Напоминалка для работы с Linux cgroup v2!

Например, cpu.max позволяет ограничить процессам доступное CPU-время, а memory.max — установить жёсткий лимит на использование оперативной памяти.

На картинке — устройство иерархии cgroup v2, основные контроллеры, системные файлы и команды для создания групп, ограничения ресурсов и перемещения процессов.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

🐱 RU Awesome DevOps — большая русскоязычная подборка материалов для DevOps и SRE-инженеров!

Здесь собрана документация по Linux, администрированию серверов, сетям и безопасности, Docker, Kubernetes, Ansible, Terraform, CI/CD, мониторингу, облачным платформам и базам данных. Отдельно есть книги, материалы по алгоритмам и вопросы для подготовки к техническим собеседованиям.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Для временной смены каталога не обязательно потом возвращаться обратно!

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

В Bash есть более простой способ — выполнить команды в подоболочке:

(
  cd /etc || exit
  ls
)

Все изменения рабочего каталога действуют только внутри круглых скобок.

После завершения блока текущая оболочка остаётся в том же каталоге:

pwd

Этот приём удобен, когда нужно последовательно обработать несколько каталогов:

(
  cd build || exit
  make
)

(
  cd tests || exit
  ctest
)

Не требуется сохранять текущий путь, использовать pushd/popd или помнить, где именно нужно выполнить обратный cd.

🔥 Подоболочка изолирует изменения рабочего каталога, переменных и других параметров окружения оболочки, поэтому после завершения блока они не влияют на текущую сессию.

🚪 Linux Ready | #совет

Создаём изменяемую копию каталога без полного копирования через OverlayFS!

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

Обычный подход потребует скопировать всё содержимое каталога независимо от того, сколько файлов фактически будет изменено:

cp -a /opt/app /tmp/app-test

В Linux для такой задачи можно использовать OverlayFS: исходный каталог подключается как нижний слой lowerdir, а все изменения, выполняемые через объединённое дерево, записываются в отдельный верхний слой upperdir.

Подготовим каталоги для writable-слоя, служебного workdir и итоговой объединённой точки монтирования:

mkdir -p /tmp/overlay/{upper,work,merged}

Для writable OverlayFS каталоги upperdir и workdir должны находиться на одной файловой системе. Файловая система верхнего слоя также должна поддерживать необходимые OverlayFS extended attributes и корректный d_type.

Монтируем /opt/app как нижний слой:

sudo mount -t overlay overlay \
  -o lowerdir=/opt/app,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work \
  /tmp/overlay/merged

После монтирования /tmp/overlay/merged представляет объединённое дерево: неизменённые объекты читаются из lowerdir, а новые и изменённые объекты обслуживаются верхним слоем.

Работать с каталогом можно как с обычным writable-деревом:

echo "test=true" >> /tmp/overlay/merged/config.ini

При первой модификации существующего файла OverlayFS выполняет copy_up: файл копируется из lowerdir в upperdir, после чего операция записи применяется уже к верхней копии. Поэтому OverlayFS не исключает копирование отдельных изменяемых файлов, но устраняет необходимость заранее копировать весь каталог.

В результате изменённая версия файла будет находиться в верхнем слое:

/tmp/overlay/upper/config.ini

Запись через /tmp/overlay/merged при этом не изменяет исходный файл:

/opt/app/config.ini

Важно то, что сам каталог /opt/app от этого физически read-only не становится. Другой процесс по-прежнему может изменить его напрямую. Изменять содержимое используемого lowerdir напрямую во время работы смонтированного OverlayFS не следует — это может привести к неопределённому поведению overlay.

Для завершения работы достаточно размонтировать объединённое представление:

sudo umount /tmp/overlay/merged

Размонтирование не удаляет содержимое upperdir: накопленные изменения сохраняются там до явной очистки каталога. Если слой действительно нужен только на время эксперимента, после успешного umount его можно удалить:

rm -rf /tmp/overlay

🔥 OverlayFS полезен, когда исходное дерево велико, а изменяется только небольшая его часть: дисковое пространство расходуется преимущественно на новые и модифицированные объекты, а запись через объединённое дерево не затрагивает исходные файлы lowerdir. Этот же механизм copy-on-write лежит в основе многих работ с контейнерными слоями и изолированными файловыми окружениями.

🚪 Linux Ready | #практика

📂 Как атакуют пароли и учётные записи!

Например, Brute Force перебирает возможные комбинации пароля, а Credential Stuffing проверяет уже утёкшие учётные данные на других сервисах.

На схеме — 6 распространённых техник, шпаргалка для системных администраторов и DevOps-инженеров: помогает понимать основные векторы компрометации учётных записей и учитывать их при настройке SSH, IAM, MFA и политик доступа.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Восстанавливаем удалённый файл через /proc, пока процесс держит его открытым!

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

Предположим, работающий сервис пишет в лог, который случайно удалили:

rm /var/log/app.log

Найти открытые файлы с нулевым количеством жёстких ссылок можно через lsof. Опция +L1 выбирает открытые файлы, у которых link count меньше 1:

sudo lsof +L1

Для удалённого лога вывод может выглядеть так:

app  4217  root  5w  REG  ...  /var/log/app.log (deleted)

Здесь 4217 — PID процесса, 5 — номер файлового дескриптора, а w означает, что он открыт на запись.

Соответствующий FD доступен через procfs:

sudo ls -l /proc/4217/fd/5

Символическая ссылка будет указывать на уже удалённый pathname:

/proc/4217/fd/5 -> /var/log/app.log (deleted)

Хотя имени файла в каталоге уже нет, открытый файловый дескриптор всё ещё связан с файловым объектом. Пока последний такой FD не закрыт, содержимое можно скопировать через /proc:

sudo cp /proc/4217/fd/5 /tmp/app.log.recovered

Проверяем восстановленную копию:

ls -lh /tmp/app.log.recovered

При необходимости сравниваем размеры:

sudo stat /proc/4217/fd/5
stat /tmp/app.log.recovered

Это не классический undelete — cp создаёт новый файл с новым inode и копирует доступное содержимое. Если процесс продолжает запись, копия не гарантирует консистентный snapshot. Доступ через /proc/<PID>/fd/<FD> также может быть ограничен правами и настройками системы. Восстановить данные нужно до закрытия последнего FD: после этого при нулевом link count ядро сможет освободить inode и блоки файла.

🔥 Поэтому после случайного rm активного файла не спешите перезапускать процесс — сначала проверьте: sudo lsof +L1. Пока FD открыт, данные ещё могут быть доступны через /proc/<PID>/fd/<FD>.

🚪 Linux Ready | #практика