Какие есть виды прав доступа у файла?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Права доступа к файлам в 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):
- 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`.
- 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 там, где классической модели прав недостаточно.