У меня есть машина FreeNAS (11.1-U1) и FreeBSD (11.1-RELEASE-p6). На FreeNAS я бы хотел zfs receive рекурсивные снимки от имени пользователя без полномочий root с делегированными привилегиями. Похоже, это хорошо работает для большинства дочерних наборов данных. Но Иокаге data наборы данных, которые можно установить в тюрьму и администрировать оттуда, они не работают:
root@freebsd:~> zfs send -RI "dozer@2018-02-21" "dozer@2018-03-08" | ssh -T -i /root/backup_key backupuser@freenas zfs receive -dvuF neo/backups/freebsd
receiving incremental stream of dozer@2018-03-03 into neo/backups/freebsd@2018-03-03
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of dozer@2018-03-07 into neo/backups/freebsd@2018-03-07
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of dozer@2018-03-08 into neo/backups/freebsd@2018-03-08
received 312B stream in 1 seconds (312B/sec)
receiving incremental stream of dozer/ROOT@2018-03-03 into neo/backups/freebsd/ROOT@2018-03-03
.
.
.
receiving incremental stream of dozer/iocage/jails/owncloud/root@2018-03-08 into neo/backups/freebsd/iocage/jails/owncloud/root@2018-03-08
received 578MB stream in 110 seconds (5.25MB/sec)
receiving incremental stream of dozer/iocage/jails/owncloud/root/data@2018-03-03 into neo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03
cannot receive incremental stream: permission denied
warning: cannot send 'dozer/iocage/jails/owncloud/root/data@2018-03-03': signal received
warning: cannot send 'dozer/iocage/jails/owncloud/root/data@2018-03-07': Broken pipe
warning: cannot send 'dozer/iocage/jails/owncloud/root/data@2018-03-08': Broken pipe
Разрешения этого конкретного дочернего элемента точно такие же, как и у родительского набора данных:
root@freenas:~ # zfs allow neo/backups/freebsd/iocage/jails/owncloud/root/data
---- Permissions on neo/backups/freebsd -----------------------------
Local+Descendent permissions:
user backupuser atime,compression,create,dedup,exec,jailed,mount,mountpoint,quota,receive,rename,reservation,setuid,userprop
Запуск zfs receive на FreeNAS как root работает должным образом.
Какие делегированные привилегии нужны моему пользователю для получения заключенных в тюрьму наборов данных iocage и, в более общем плане, есть ли способ сделать zfs receive выдать более подробное сообщение об ошибке, в котором указано, какое разрешение отсутствует?
При устранении проблем с разрешениями, возникающих из zfs команды, проанализируйте zfs операции с точки зрения составляющих ее этапов.
Пример команды zfs receive -duvF распаковывается в несколько шагов. Два из этих флагов не относятся к каким-либо специальным разрешениям:
-d влияет на название нового набора данных (если есть)
-v включает подробный вывод
У двух других есть.
-F означает, что файловая система будет откат к исходному снимку инкрементальной передачи до начала приема
-u означает, что файловая система не будет смонтирована после завершения приема
Я подозреваю, что вам не хватает разрешения на откат. Флаг -F в вашей команде означает, что zfs rollback будет выполнено, и ваш zfs allow не перечисляет rollback.
В общем случае можно делать дедуктивные предположения о разрешениях, необходимых для данного zfs команда.
Страница руководства для zfs указывает на то:
Имена разрешений совпадают с именами подкоманды и свойств ZFS.
и ...
Как правило, разрешения - это возможность использовать подкоманду ZFS или изменять свойство ZFS. Доступны следующие разрешения:
NAME TYPE NOTES allow subcommand Must also have the permission that is being allowed clone subcommand Must also have the 'create' ability and 'mount' ability in the origin file system create subcommand Must also have the 'mount' ability destroy subcommand Must also have the 'mount' ability diff subcommand Allows lookup of paths within a dataset given an object number, and the ability to create snapshots necessary to 'zfs diff' hold subcommand Allows adding a user hold to a snapshot mount subcommand Allows mount/umount of ZFS datasets promote subcommand Must also have the 'mount' and 'promote' ability in the origin file system receive subcommand Must also have the 'mount' and 'create' ability release subcommand Allows releasing a user hold which might destroy the snapshot rename subcommand Must also have the 'mount' and 'create' ability in the new parent rollback subcommand Must also have the 'mount' ability send subcommand share subcommand Allows sharing file systems over the NFS protocol snapshot subcommand Must also have the 'mount' ability groupquota other Allows accessing any groupquota@... property groupused other Allows reading any groupused@... property userprop other Allows changing any user property userquota other Allows accessing any userquota@... property userused other Allows reading any userused@... property aclinherit property aclmode property atime property canmount property casesensitivity property checksum property compression property copies property dedup property devices property exec property filesystem_limit property logbias property jailed property mlslabel property mountpoint property nbmand property normalization property primarycache property quota property readonly property recordsize property refquota property refreservation property reservation property secondarycache property setuid property sharenfs property sharesmb property snapdir property snapshot_limit property sync property utf8only property version property volblocksize property volsize property vscan property xattr property
Этот пример включает в себя -u флаг, поэтому файловая система не будет смонтирована в конце операции приема. Однако если -u отсутствовали, файловая система была бы смонтирована в конце процесса приема. Что характерно, receive разрешение требует mount разрешение.
Потому что zfs mount операция автоматически создаст любые необходимые точки монтирования, пользователь может иметь zfs разрешение на монтирование набора данных, но не имеет разрешений файловой системы для создания точки монтирования. В случае zfs mount, монтирование выйдет из строя. В zfs create или rename При выполнении операции файловая система будет создана или переименована, но останется отключенной, если у пользователя недостаточно прав файловой системы для создания точки монтирования.
Аналогично zfs rename Команда могла завершиться ошибкой из-за отсутствия разрешений на нескольких этапах операции переименования. В общих словах, этапы компонента могут быть следующими:
1) размонтируйте файловую систему (mount разрешение)
2) создать новую файловую систему (create разрешение)
3) сопоставьте метаданные файловой системы с новым именем (rename разрешение)
Четвертый шаг - перемонтировать файловую систему с новым именем в ее новой, возможно измененной точке монтирования, которая снова использует mount разрешение и, возможно, разрешения файловой системы для создания новой точки монтирования.
Я таких приемов не тестировал, но видно, что zfs различает create и rename разрешения, а также между mount и mountpoint разрешения. Можно представить, что можно разрешить пользователю создавать новые файловые системы, но после создания пользователь не может их переименовать. Для файловых систем с унаследованными точками монтирования переименование файловой системы часто также приводит к переименованию точки монтирования файловой системы, как при переименовании tank/usr/local к tank/usr/local.OLD изменяет точку монтирования с /usr/local к /usr/local.OLD.
Разделение mount или rename из mountpoint Permissions означает, что пользователю может быть разрешено переименовывать файловую систему, но не разрешено изменять ее точку монтирования. Или наоборот, чтобы иметь возможность изменить место монтирования файловой системы, но не иметь возможности изменить имя файловой системы.
Богатство операций с файловой системой и делегирование этих операций в сочетании с детализацией разрешений могут сделать zfs несколько сложный, но очень мощный.
Похоже, у вас есть снимок, на котором отсутствует разрешение.
Попробуйте установить receive разрешение на neo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03.
Похоже, что он настроен правильно на томе, но отсутствует на снимке.