Umask: разбор маски прав и её влияния на файлы и каталоги
Недавно настраивал сервер для нового проекта. После деплоя заметил, что файлы логов создаются с правами 644. А я ожидал 600. Почему?
Предыстория
Скрипт на Python пишет логи. В коде ничего не менял. Но сервер — стандартный образ Ubuntu. Пришлось разбираться.
Проблема
Оказалось, что дело в umask. По умолчанию в системе стоит значение 022. Оно убирает права на запись для группы и остальных. Но для логов с конфиденциальными данными это слишком открыто.
Umask — это не права, а маска. Она вычитается из максимальных прав: 666 для файлов, 777 для каталогов.
Почему это важно
Если права слишком широкие, информация может утечь. Если слишком узкие — приложение не сможет писать файлы. Для бизнеса это либо уязвимость, либо отказ в обслуживании.
Решение
Я изменил umask для процесса логирования. В systemd unit добавил строку UMask=007. Теперь максимальные права для файлов 666, вычитаем 007 — получаем 660. Для каталогов 777 - 007 = 770.
- 🔍 Проверил текущий umask командой umask в терминале
- ⚙️ Добавил UMask=007 в секцию Service systemd unit файла
- 🔄 Выполнил systemctl daemon-reload и restart сервиса
Результат
После изменений новые файлы логов создаются с правами 660, а каталоги — 770. Приложение работает стабильно, данные защищены. С тех пор всегда проверяю umask при развёртывании новых сервисов.
📬 Свяжитесь с нами
Хотите внедрить это в своем бизнесе? Пишите нам!
- 📧 Email: [email protected]
- 🌐 Сайт: 1it.pro
- 📝 Блог: blog.1it.pro
- ✈️ Telegram Global (EN): Admin_global
- ✈️ Telegram (RU): Admin