← Назад к вопросам

Какие есть виды прав доступа у файла?

1.0 Junior🔥 231 комментариев
#Linux и администрирование#Безопасность

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Права доступа к файлам в Linux/UNIX системах

В контексте систем Linux/UNIX, которые являются основой большинства DevOps-инфраструктур, существуют три основных вида прав доступа (permissions) к файлам и директориям, реализованные через классическую модель дискреционного управления доступом (DAC).

1. Базовые права доступа (Basic Permissions)

Это наиболее известная система, отображаемая командой ls -l. Она состоит из трех категорий прав для трех типов пользователей:

# Пример вывода ls -l
-rwxr-xr-- 1 user group 2048 Jan 10 10:30 script.sh
# ↑ Права ↑     ↑ Владелец и группа

Права разбиты на три группы по три символа:

  • Права владельца (user/owner): Первые три символа (например, rwx)
  • Права группы (group): Вторые три символа (например, r-x)
  • Права остальных (others): Третьи три символа (например, r--)

Каждая группа может содержать комбинацию из трех базовых прав:

  • r (read) — чтение (для файла: просмотр содержимого; для директории: листинг файлов).
  • w (write) — запись (для файла: изменение; для директории: создание/удаление файлов).
  • x (execute) — выполнение (для файла: запуск как программы; для директории: возможность cd в нее).

Эти права часто задаются восьмеричным (octal) форматом, где каждая группа — это цифра от 0 до 7:

# Установка прав 755: владелец — rwx, группа — r-x, остальные — r-x
chmod 755 script.sh

# Аналогичная установка символьным форматом
chmod u=rwx,go=rx script.sh

2. Расширенные права доступа (Special Permissions / Setuid/Setgid/Sticky Bit)

Помимо базовых rwx, существуют три специальных флага, которые занимают позицию бита выполнения (x):

  1. Set User ID (SUID / setuid) — обозначается как s в позиции x для владельца.
    *   **Смысл**: Файл с установленным SUID **выполняется с правами его владельца**, а не пользователя, который его запустил.
    *   **Пример**: `passwd` (`/usr/bin/passwd`), который должен редактировать `/etc/shadow` (доступен только root).
    *   **Установка**: `chmod u+s file` или `chmod 4755 file`.

```bash
ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root root 59976 Nov 24  2022 /usr/bin/passwd
```

2. Set Group ID (SGID / setgid) — обозначается как s в позиции x для группы.

    *   **Для файлов**: Аналогично SUID, но выполнение происходит с правами **группы-владельца файла**.
    *   **Для директорий (важнее в DevOps)**: Все **новые файлы и поддиректории**, созданные внутри, будут наследовать **группу-владельца родительской директории**, а не первичную группу пользователя. Критически важно для shared-папок (например, `/var/www`).
    *   **Установка**: `chmod g+s directory` или `chmod 2770 directory`.

  1. Sticky Bit — обозначается как t в позиции x для остальных.
    *   **Смысл**: Применяется только к директориям. Разрешает удаление/переименование файла в директории **только его владельцу, владельцу директории или root**. Без sticky bit любой пользователь с правом записи (`w`) в директорию может удалить любой файл.
    *   **Классический пример**: Директория `/tmp`.
    *   **Установка**: `chmod o+t /tmp` или `chmod 1777 /tmp`.

```bash
ls -ld /tmp
# drwxrwxrwt 15 root root 4096 Jan 10 10:35 /tmp
```

3. Расширенные списки контроля доступа (ACL — Access Control Lists)

Классическая модель «владелец-группа-остальные» часто недостаточна. ACL предоставляют гораздо более гибкую систему, позволяя задавать права для произвольного количества пользователей и групп на один объект.

# Просмотр ACL файла
getfacl script.sh

# Установка ACL: разрешить пользователю 'jenkins' читать и выполнять файл
setfacl -m u:jenkins:rx script.sh

# Установка ACL: разрешить группе 'developers' читать и писать
setfacl -m g:developers:rw script.sh

# Установка ACL по умолчанию для директории (будут наследоваться новыми файлами)
setfacl -m d:g:developers:rwX shared_dir/

Ключевые возможности ACL:

  • Множественные записи для разных пользователей/групп.
  • Маски (mask), которые определяют максимальные эффективные права.
  • Наследование (default ACL) для директорий.

Практическое значение для DevOps

Понимание всех трех видов прав критически важно для DevOps-инженера:

  • Безопасность: Некорректные права (например, 777 на конфиги с паролями) — частая причина уязвимостей. SUID-файлы требуют особого аудита.
  • Совместная работа: setgid на директориях и ACL — стандартный способ организовать корректный общий доступ к логам, коду или данным между членами команды и сервисными аккаунтами (например, nginx, jenkins).
  • Автоматизация и IaC: Права должны корректно прописываться в Ansible playbooks, Terraform-скриптах, Dockerfile и Kubernetes ConfigMaps/Secrets. Ошибки ведут к падению приложений.
  • Устранение неполадок: Проблемы "Permission denied" — одни из самых частых. Инженер должен быстро прочитать (ls -la, getfacl), проанализировать и исправить (chmod, chown, setfacl) права.

Таким образом, эффективный DevOps-инженер должен свободно оперировать не только базовыми chmod 644, но и понимать применение setgid для общих директорий, опасность неконтролируемых SUID-бинарников и использовать ACL там, где классической модели прав недостаточно.