Проблема каталога группы

Я бы предпочел использовать sudo , а не ACL. (В вопросе нет явного упоминания NFS, поэтому я предполагаю, что root_squash не является проблемой.)

Начните с вашего каталога с разрешениями 1777 (липкие плюс все чтение / запись) как вы предложили.

Создайте этот сценарий с именем файла, например / usr / local / bin / rmd . Измените определение TARGET так, чтобы это был абсолютный путь к целевому каталогу.

#!/bin/bash
#
# Remove files from $TARGET. Some care is taken to avoid escaping from
# the path root
#
########################################################################
#
TARGET='/tmp'

ERROR=
for ITEM in "$@"
do
    LINK=$(readlink -f "$ITEM")
    if test -n "$LINK" && echo "$LINK" | grep -vq "^$TARGET/"
    then
        echo "Suspicious path: $ITEM" >&2
        ERROR=yes
    fi
done
test yes = "$ERROR" && exit 1

exec rm "$@"

Добавьте следующую запись в файл sudoers (используйте visudo для редактирования этот файл). Измените admin на пользователя с правами администратора для удаления файлов в целевом каталоге.

admin ALL = NOPASSWD: /usr/local/bin/rmd

Поскольку нам известно, что rmd находится в / usr / local / bin можно было бы повторно exec скрипт, если у него не было достаточных привилегий, и таким образом, чтобы администратор не забывал использовать sudo , но я пропустил это сейчас. Дайте мне знать, если вы хотите эту настройку скрипта.

Пример использования

$ ls -l /tmp
lrwxrwxrwx 1 roaima roaima 4 Mar 31 00:17 etc -> /etc
-rw-r--r-- 1 roaima roaima 0 Mar 31 00:29 one
lrwxrwxrwx 1 roaima roaima 2 Mar 31 00:20 root -> ..
-rw-r--r-- 1 roaima roaima 0 Mar 31 00:29 two

$ sudo rmd /tmp/etc/hosts /tmp/root/etc/motd /tmp/one
Suspicious path: /tmp/etc/hosts
Suspicious path: /tmp/root/etc/motd

$ ls /tmp
etc  one  root  two

$ sudo rmd /tmp/one /tmp/root
$ ls /tmp
etc  two

Bindfs - одно из возможных решений. Я назвал своего опытного администратора nradmin , и вот пример:

mkdir /uploads
chmod 1777 /uploads

mkdir /home/nradmin/manage-uploads
bindfs -u nradmin -p ud+rwx /uploads /home/nradmin/manage-uploads

Каждый файл и каталог в смонтированной цели принадлежит nradmin . -p ud + rwx делает каждый каталог с разрешениями "rwx" для владельца каталога. Поскольку nradmin является владельцем всех каталогов и имеет в них полные права владельца, он может успешно удалить в них любой файл, даже рекурсивно.

Альтернативным подходом может быть код ограниченного ] chroot () реализация / bin / rm и выполните ее как root . chroot () может быть экранирован процессом, запущенным root , но только если вы дадите этому процессу свободу выполнять все, что он хочет. Простой двоичный файл C, который сначала делает chdir () & chroot () в каталог / uploads , а затем вызывает только unlink () ] или rmdir () должны быть безопасными. Но для этого требуется много кода, например, рекурсивное удаление каталогов, параметр командной строки, например -f , чтобы игнорировать несуществующие файлы и т. Д.

Вот одно простое решение. Считайте, что администратором является admin , а наш специальный каталог должен быть / tmp / special .

mkdir /tmp/special
chmod 1777 /tmp/special
chown admin:admin /tmp/special
ls -ld /tmp/special
drwxrwxrwt 2 admin admin 4096 Apr  3 21:34 /tmp/special

Любой пользователь может создавать / редактировать / удалять свои собственные файлы в ] / tmp / special .Пользователь admin может удалить любой файл (хотя и с предупреждениями от rm ).

NB. Если пользователь создает каталог в / tmp / special , административный пользователь не может его удалить. Это может быть препятствием для этого решения, но, поскольку в вашем вопросе упоминались только файлы , а не каталоги , я чувствовал, что это стоит предложить.

Полный объем этой проблемы неясен, так как мы не знаем, каков сценарий использования. Однако с помощью меток SELinux можно добиться того, о чем вы просите. SELinux дает вам детальный контроль над тем, кто что и где делает. Если количество пользователей «ограничено» и «известно» - наличие определенных контекстов / меток, связанных с каждым из них, не является большой проблемой, тогда нужно написать небольшую политику в коде ваших требований.

Хм ... как насчет перехода в / special_folders_root / special_folder /./ , чтобы избежать проблем с корневыми каталогами, принадлежащими root? См. Документацию vsftpd (например) для объяснения посторонних точек в пути.

Не уверен, если следующее будет полезно, но: У нас есть доля самбы с субдирами. Сетевые MFU, помещающие отсканированные документы в определенные подкаталоги (MFU01 -> / share / 001 /, MFU15--> / share / 015 / и т. д.). Пользователи (из Windows) могут изменять или удалять файлы в любом из этих подкаталогов, но не могут удалять подкаталоги. Я сделал это, используя ACL в стиле Windows, но я ничего не знаю о ACL NFS

NB! Не за щедрость, а за помощь.

ماذا عن هذا الأسلوب:

احتفظ بالملفات الأصلية التي تم تحميلها في دليل منفصل ، لكل مستخدم. يغطي هذا الحوكمة وأذونات الحذف.

في $ share ، كل شيء عبارة عن رابط للملفات الأصلية ، وقوائم التحكم في الوصول للمالك / المشرف موجودة.

في النهاية ، كل عنصر في $ share رابط العودة. أي شيء ليس رابط يتم نقله إلى مجلد مالك (رافع).