Почему при создании папки права равны 777?

Отличный вопрос, который затрагивает фундаментальные аспекты работы с правами доступа в Unix-подобных системах, такие как umask (user file creation mask) и поведение файловой системы.

Краткий ответ

Коротко: папка (директория) не создается с правами 777 (rwxrwxrwx) по умолчанию. Она создается с базовыми правами 777, но затем на них немедленно накладывается маска текущего пользователя — umask. Именно umask определяет, какие биты прав будут "вычтены" из этого базового значения, чтобы получить фактические права новой директории.

Таким образом, если вы видите, что только что созданная папка имеет права 777, это означает, что umask вашей текущей сессии равен 0000.

Подробное объяснение

Процесс создания файла или директории с точки зрения прав доступа состоит из двух шагов:

1. Базовые (исходные) права

• Для директорий: система использует базовое значение 0777 (rwxrwxrwx). Это максимально возможные права, символизирующие "полный доступ для всех".
• Для обычных файлов: система использует базовое значение 0666 (rw-rw-rw-). Право на выполнение (x) по умолчанию не дается, так как это потенциально опасно.

Эти значения жестко зашиты в логику системных вызовов (например, mkdir(), open()).

2. Применение umask

Umask — это маска процесса (обычно наследуемая от оболочки — bash, zsh), которая определяет, какие биты прав должны быть запрещены при создании нового объекта. Это механизм безопасности по умолчанию.

Umask представляется восьмеричным числом (например, 0022, 0002). Он применяется побитовой операцией AND с инверсией (NOT) к базовым правам:

Фактические_права = Базовые_права & (~umask)

Практические примеры

Давайте посмотрим, как это работает в командной строке. Сначала проверим текущий umask:

# Проверяем текущую umask (чаще всего в восьмеричном формате)
umask
# Типичный вывод для обычного пользователя: 0002
# Или в символьном виде:
umask -S
# Вывод: u=rwx,g=rwx,o=rx

Теперь создадим папку с разными значениями umask:

# Пример 1: Стандартный umask 0022 (часто используется по умолчанию в root-сессиях)
$ umask 0022
$ mkdir test_dir_1
$ ls -ld test_dir_1
drwxr-xr-x 2 user group 4096 Apr 15 10:00 test_dir_1
# Права: 755 (777 - 022). Группе и другим запрещена запись (w).

# Пример 2: "Расслабленный" umask 0002 (часто по умолчанию для обычных пользователей)
$ umask 0002
$ mkdir test_dir_2
$ ls -ld test_dir_2
drwxrwxr-x 2 user group 4096 Apr 15 10:00 test_dir_2
# Права: 775 (777 - 002). Другим запрещена запись (w).

# Пример 3: Umask 0000 (причина появления прав 777)
$ umask 0000
$ mkdir test_dir_3
$ ls -ld test_dir_3
drwxrwxrwx 2 user group 4096 Apr 15 10:00 test_dir_3
# Права: 777 (777 - 000). Все биты разрешены.

Почему umask=0000 и права 777 — это плохо (с точки зрения DevOps)

С точки зрения инженера DevOps и безопасности, директория с правами 777 — это критическая уязвимость и антипаттерн. Вот почему:

1. Грубое нарушение принципа наименьших привилегий: Любой пользователь или процесс в системе может удалить, переименовать или создать файлы внутри такой директории. Это особенно опасно, если директория принадлежит системному пользователю (например, www-data для веб-сервера).
2. Уязвимость для атак: Злоумышленник, получивший доступ к системе под любым, даже самым ограниченным пользователем, может модифицировать содержимое таких папок. Классический пример — подмена скриптов или библиотек веб-приложения.
3. Проблемы в совместном использовании: Хотя 777 может казаться простым решением для общего доступа, это "дубина". Гораздо правильнее использовать механизм групп Linux: назначить папке нужную группу и права типа 775 (rwxrwxr-x), где запись разрешена только владельцу и группе.

Как это исправить и где смотреть

Если вы столкнулись с этой проблемой в продакшене:

1. Немедленно исправить права на проблемные директории:

   # Установить адекватные права (например, 755 для системных папок)
   chmod 755 /path/to/problematic_directory
   # Или, если нужен групповой доступ:
   chmod 775 /path/to/shared_directory
   chgrp dev_team /path/to/shared_directory
   

2. Найти корень проблемы — откуда берется umask=0000:

    *   Проверить файлы конфигурации оболочки пользователя: `~/.bashrc`, `~/.bash_profile`, `~/.profile`, `/etc/profile`, `/etc/bash.bashrc`. В них может быть строка `umask 0000`.
    *   Проверить **systemd-сервисы**. В `[Service]`-секциях unit-файлов может быть директива `UMask=0000`.
    *   Проверить **CI/CD пайплайны** (Jenkinsfile, .gitlab-ci.yml). В скриптах Runner'ов или агентов мог быть установлен такой umask.
    *   Проверить **Dockerfile**. В инструкциях сборки образа могла быть команда `RUN umask 0000`, что делает проблему системной для всех контейнеров, собранных из этого образа.

Правильный подход DevOps

• Явное указание прав при создании: В скриптах не полагайтесь на umask по умолчанию.

  mkdir -m 755 /opt/myapp/logs  # Явно задаем нужные права
  

• Контроль umask на уровне инфраструктуры: Устанавливайте безопасный umask по умолчанию через Puppet, Ansible, Chef или cloud-init.
• Security as Code: Включите проверку прав доступа в статические анализаторы кода (SAST) и пайплайны безопасности (например, GitLeaks, Trivy для конфигураций).
• Использование ACL для сложных сценариев: Если стандартных прав недостаточно, используйте Access Control Lists (setfacl/getfacl), а не 777.

Вывод: Права 777 у новой папки — это красный флаг, указывающий на неправильно сконфигурированный umask=0000. Понимание этого механизма критически важно для построения безопасных и предсказуемых сред, от контейнеров до bare-metal серверов. Всегда начинайте с безопасного umask (например, 0027 или 0022) и расширяйте права осознанно, только при реальной необходимости.