Почему новый файл обычно получает
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 | #практика