Как заставить пользователей устанавливать ACL на каталоги, которые им не принадлежат?
Вы почти наверняка столкнетесь с проблемой, заключающейся в том, что раскрытие тильды происходит до раскрытия параметра, что можно объяснить кратким примером:
$ cd ~kaz
kaz $ var='~kaz'
kaz $ echo $var
~kaz
kaz $ cd $kaz
bash: cd: ~kaz: No such file or directory
Эту проблему можно решить с помощью eval . В любом случае вам понадобится eval , потому что вы извлекаете команды из истории, и они могут содержать произвольные расширения, например:
$ mv file.tex ~/Documents/$(compute_folder_name foo-param)/subfolder1
$ follow
(Есть проблемы, такие как повторное расширение эти значения могут больше не соответствовать исходному раскрытию. Предположим, compute_folder_name - это функция, которая увеличивает некоторую глобальную переменную.)
Вместо сценария оболочки setuid рассмотрите возможность включения определенного сценария с помощью sudo.
Несмотря на то, что чаще всего он используется таким образом, sudo не ограничивается «разрешить кому-либо выполнять любую программу от имени пользователя root». Вы можете легко настроить «пользователям A, B и C разрешено выполнять только этот конкретный скрипт от имени пользователя root» в /etc/sudoers. Подробнее см. man sudoers.
На самом деле нет преимуществ использования sudo вместо сценария setuid, за исключением того, что в системах, где сценарии setuid полностью отключены по соображениям безопасности, второй вариант просто не будет работать вообще. Вы по-прежнему можете написать собственный двоичный файл setuid, но вставка строки в sudoers проще, быстрее и легче изменить позже, когда вы захотите добавить или удалить пользователей.
Использование сценария оболочки, вероятно, не сработает, поскольку сценарии оболочки setuid обычно не поддерживаются в Linux.
В качестве обходного пути можно было бы написать небольшой исполняемый файл на языке C, чтобы обеспечить необходимую функциональность, и установить для него root-права.