Каталог доступен на запись, но чужой файл не удаляется: sticky bit

Два пользователя могут создавать файлы в общей папке. Один пытается удалить файл другого и получает Operation not permitted, хотя каталог доступен на запись. Это может быть намеренная защита sticky bit: общий каталог разрешает приносить свои данные, но ограничивает удаление чужих имён.

Проверить каталог, а не только файл

ls -ld /srv/dropbox
stat -c '%n %a %U %G' /srv/dropbox /srv/dropbox/result.csv
id

Например, режим каталога 1777 отображается как drwxrwxrwt. Последняя t означает sticky вместе с правом прохода для others. Большая T указывала бы на отсутствие этого x. Удаление имени определяется правами каталога и дополнительными условиями, поэтому режим 0666 самого файла не даёт автоматического права удалить его из защищённой папки.

При sticky удалить или переименовать объект обычно может владелец файла, владелец каталога либо процесс с соответствующей привилегией. Правила специальных битов описаны в chmod(2). Проверка от root скроет различие, ради которого механизм включён.

Определить нужную модель работы

Для входящей папки, куда разные пользователи складывают независимые результаты, запрет удаления чужих файлов полезен. Для совместного редактирования одного набора документов он может мешать: редактор часто сохраняет через временный файл и переименование поверх исходного. Пользователь сможет записать байты в доступный файл, но замена имени может отказать.

Уточните реальную операцию приложения. Если простая запись работает, а сохранение из редактора нет, проверьте его способ сохранения и владельца целевого объекта. Не убирайте sticky только потому, что сообщение интерфейса короткое: вы одновременно разрешите участникам каталога удалять чужие имена.

Проверить на отдельном каталоге

mkdir /srv/dropbox-lab
chmod 1777 /srv/dropbox-lab
ls -ld /srv/dropbox-lab

Создание под /srv обычно требует администратора. Используйте новый пустой учебный каталог и две тестовые учётные записи. Первый пользователь создаёт файл, второй пробует создать собственный и удалить первый. Ожидается успех создания и отказ чужого удаления. Владелец первого файла должен иметь возможность удалить его сам.

Это проверяет именно политику общего каталога. Не используйте chmod 1777 на папке с конфиденциальными данными: такой режим открывает всем создание и проход, а видимость содержимого зависит от r. Sticky ограничивает удаление, но не скрывает имена и не запрещает чтение файлов с открытыми правами.

Сделать доступ удобным

Если пользователям нужен общий управляемый набор, выделите группу, настройте права каталога и файлов и определите владельца процесса публикации. Для входящей папки можно оставить sticky, а обработку переносить в отдельное дерево с другой политикой. Это понятнее, чем постоянное ручное снятие бита на время работы.

После изменения проверьте создание, чтение, перезапись и удаление раздельно. Они используют разные условия доступа. Запишите ожидаемое поведение каждой роли в инструкции, чтобы очередной инженер не «исправил» осознанное ограничение.

Посмотрите программу Linux и Bash для DevOps-инженеров. Практика с пользователями и правами помогает проектировать общий каталог под конкретный рабочий процесс и проверять доступ обычными учётными записями.

Ещё по теме

• После mount файлы исчезли: как найти скрытые данные каталога
• Новые файлы получают разные группы: настраиваем setgid каталога