После диплоинга возникли проблемы, девопс говорит проверить выставленный StickBid на определенной директории, как проверить

Проверка выставленного Sticky Bit (StickyBid) на директории

Для начала, важно понимать, что Sticky Bit (часто ошибочно называемый "StickyBid") — это специальный разрешительный бит в Unix/Linux системах, применяемый к директориям. Его основная функция — предотвратить удаление или переименование файлов в директории пользователями, которые не являются владельцами этих файлов или самой директории. Это критически важно для общих директорий, таких как /tmp, где многие пользователи имеют права на запись.

Как проверить, установлен ли Sticky Bit на директории

Проверка выполняется с помощью команды ls с флагом -ld (чтобы смотреть на саму директорию, а не её содержимое).

ls -ld /путь/к/вашей/директории

Анализ вывода команды

В выводе команды первая колонка показывает права доступа (permissions). Если Sticky Bit установлен, вы увидите букву t или T в последней позиции прав для "others" (всех остальных).

Пример вывода без Sticky Bit:

drwxrwxrwx   2 user group  4096 May 27 10:00 /tmp/shared_dir

Пример вывода с установленным Sticky Bit:

drwxrwxrwt   2 user group  4096 May 27сы 10:00 /tmp

или

drwxrwxrwT   2 user group  4096 May 27 10:00 /tmp/another_dir

• Строчная t: Означает, что Sticky Bit установлен и у "others" есть право на выполнение (x).
• Заглавная T: Означает, что Sticky Bit установлен, но у "others" нет права на выполнение (x).

Альтернативные методы проверки

Информацию о Sticky Bit можно получить и другими способами:

1. Использование stat команды (более детальный и машиночитаемый вывод):

   stat /путь/к/вашей/директории
   

    Ищите в выводе строку `Access: (0777/drwxrwxrwt)` или числовое значение прав.

1. Проверка числового (octal) представления прав:

    Sticky Bit имеет числовое значение **1000** и добавляется к стандартным правам (например, 755).

```bash
ls -ld /путь/к/директории | awk '{print $1}'
```

    Можно также использовать `find`:

```bash
find /путь/к/директории -maxdepth 0 -printf "%m\n"
```

    Если вывод начинается с `1` (например, `1777`), значит Sticky Bit установлен. `1777` = `0777` (полные права) + `1000` (Sticky Bit).

Практический пример и шаги для DevOps

Предположим, проблема после деплоя связана с общей директорией /var/www/uploads, куда должно писать приложение.

Пошаговая инструкция проверки и исправления:

1. Проверка текущего состояния:

   ls -ld /var/www/uploads
   # или
   stat /var/www/uploads
   

2. Анализ результата:

    *   Если видите `drwxrwxrwt` — Sticky Bit установлен корректно.
    *   Если видите `drwxrwxrwx` — Sticky Bit **не установлен**, что может быть причиной проблемы (пользователи могут удалять чужие файлы).

1. Установка Sticky Bit (если он отсутствует):

    Используйте команду `chmod` с числовой или символьной нотацией.

```bash
# Символьная нотация: добавление 't' для 'others'
sudo chmod o+t /var/www/uploads

# Числовая нотация: добавление 1000 к текущим правам.
# Сначала узнайте текущие права в числовом виде:
CURRENT_MODE=$(stat -c '%a' /var/www/uploads)
sudo chmod $((CURRENT_MODE + 1000)) /var/www/uploads
# Например, если права были 0775, команда будет: chmod 1775 /var/www/uploads
```

4. Проверка изменений: bash ls -ld /var/www/uploads

    Убедитесь, что в выводе появилась `t` или `T`.

Критические замечания для DevOps-инженера

• Безопасность: Sticky Bit — не панацея. Убедитесь, что владелец и группа директории установлены правильно (например, www-data:www-data для веб-cервера), а базовые права (например, 775) ограничивают доступ там, где это необходимо.
• Логирование и мониторинг: Если проблема была в отсутствии Sticky Bit, добавьте его проверку в ваши Ansible плейбуки, Terraform provisioners или скрипты настройки Packer.
• Расследование инцидента: Узнайте у разработчиков, какие именно операции (удаление, переименование) приводят к ошибке после деплоя. Это подтвердит гипотезу о проблеме с правами.

Вывод: Проверка Sticky Bit — это быстрое действие, выполняемое командами ls -ld или stat. Его отсутствие в общих директориях записи — классическая причина проблем с целостностью файлов после деплоя, когда несколько процессов или пользователей работают с одним пространством.