Не я первый, не я последний, кому понадобилось организовать некое хранилище, в которое пользователи, принадлежащие к определённой группе, имели бы возможность что-то складывать, забирать, удалять и т.д., или, выражаясь более простым языком, файловую "помойку". Естественным образом такое хранилище не является верхом защищённости и безопасности и не предназначено для хранения business critical информации, но "помойка" на то и помойка, что потеря какой либо её части не должна быть критичной.
В Solaris на UFS данная задача решалась правильным использованием команды setfacl(1), но для ZFS данный путь не применим, так как с одной стороны для изменения Access Control List (ACL) на ZFS используется команда chmod(1), а с другой стороны одного изменения ACL оказалось недостаточно. Вроде бы и задача простая и на docs.sun.com имеется русскоязычная документация по ZFS, но потратить несколько часов на осознание всей доступной информации всё таки пришлось.
Если коротко, то при условии, что пользователи принадлежат к группе groupname, а для "помойки" будет использоваться tank/garbage, то необходимо выполнить следующие действия:
zfs create tank/garbage
zfs set aclinherit=passthrough tank/garbage
zfs set aclmode=passthrough tank/garbage
chmod A+group:groupname:rwxpdDaARWcCos:fd:allow /tank/garbage
Если "помойка" уже существовала, то первая команда не нужна, зато потребуется установить ACL-ы на уже созданные каталоги и файлы:
gfind /tank/garbage -mindepth 1 -type d -print0 | gxargs -0 chmod A+group:groupname:rwxpdDaARWcCos:fdi:allow
gfind /tank/garbage -mindepth 1 -type f -print0 | gxargs -0 chmod A+group:groupname:rwxpdDaARWcCos::allow
Всё. Можно работать. Результат можно проверить используя команду:
ls -V /tank/garbage
Если немного разобрать приведённые команды, то:
- Изменение aclmode и aclinherit полностью разрешает прозрачное наследование ACL, по умолчанию aclmode=groupmask и aclinherit=restricted, что несколько более безопасно для данных. Из-за необходимости изменения данных свойств я и рекомендую для "помойки" использовать отдельную файловую систему.
- Конструкция
A+group:groupname:rwxpdDaARWcCos:fd:allow
имеет следующее значение:
- A - для chmod(1) означает управление ACL.
- + - ACL будет добавлен первым по списку.
- group:groupname - ACL относится группе с именем groupname.
- rwxpdDaARWcCos - полный набор всех возможных прав. Честно говоря некоторые из них дублируются другими имеющимися по умолчанию правами, а некоторые, например A и o, для перестраховки и вовсе можно убрать.
- fd - наследовать данный ACL для файлов и каталогов данного каталога. Во втором случае, когда устанавливается ACL для существующих подкаталогов добавлена буковка i - такой ACL действует только на файлы и подкаталоги, но не на сам каталог, так как на него уже оказывает действие ACL вышестоящего каталога. А для файлов наследование и вовсе невозможно, из-за чего для них это поле пустое.
- allow - ACL является разрешающим.
Хочу заметить, что ufsrestore(1M), как ни странно, умеет работать с NFSv4 ACL, поэтому, если Вы существующую "помойку" с UFS с установленными через setfacl(1) правами захотите перенести на ZFS методом ufsdump | ufsrestore, то ufsrestore попытается восстановить установленные ранее ACL. Только вот в результате на файлы и каталоги устанавливается более 20-ти ACL-ов, в корректности которых мне честно говоря стало лень разбираться. Поэтому я решил, что проще сначала удалить все установленные ufsretore-ом ACL:
chmod -R A- /tank/garbage
А потом уже поставил новые ACL.
Внимание! Если у Вас установлен пакет SFWcoreu (coreutils - GNU core utilities) с Companion Software DVD, то следует убедиться в том, что ls и chmod используются из /usr/bin, так как в SFWcoreu также входят ls и chmod, но вот работать с NFSv4 ACL они не умеют.