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

Я был бы склонен решить с 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 дает вам детальный контроль над тем, кто что и где делает. Если количество пользователей «ограничено» и «известно» - наличие определенных контекстов / меток, связанных с каждым из них, не является большой проблемой, тогда нужно написать небольшую политику для кода в ваших требованиях.

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

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

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

Как насчет этого подхода:

Храните исходные загруженные файлы в отдельном каталоге для каждого пользователя. Это касается управления и разрешений на удаление.

В $share, все является ссылкой на исходные файлы, и списки управления доступом владельца / администратора имеются.

В конце концов, каждый предмет в $share это обратная ссылка. Все, что не ссылка перемещается в папку владельца (загрузившего).