Tengo una máquina FreeNAS (11.1-U1) y FreeBSD (11.1-RELEASE-p6). En FreeNAS, me gustaría realizar zfs receiveinstantáneas recursivas como usuario no root con privilegios delegados. Esto parece funcionar bien para la mayoría de los conjuntos de datos secundarios. Pero los conjuntos de datos de iocage data, que pueden montarse en la cárcel y administrarse desde allí, fallan:
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
Los permisos de ese niño en particular son exactamente los mismos que los del conjunto de datos principal:
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
Ejecutar zfs receiveFreeNAS como root funciona como se esperaba.
¿Qué privilegios delegados necesita mi usuario para recibir los conjuntos de datos encarcelados de iocage y, en términos más generales, hay alguna manera de mostrar zfs receiveun mensaje de error más detallado que indique qué permiso falta?
Respuesta1
Al solucionar problemas de permisos que surgen de zfslos comandos, analice la zfsoperación en términos de los pasos que lo componen.
El comando de muestra de zfs receive -duvFse descomprime en varios pasos. Dos de esas banderas no se relacionan con ningún permiso especial:
-d afecta el nombre del nuevo conjunto de datos (si corresponde)
-v habilita la salida detallada
Los otros dos sí.
-F significa que el sistema de archivos volverá a la instantánea inicial de la transferencia incremental antes de que comience la recepción
-u significa que el sistema de archivos no se montará después de que finalice la recepción
Mi corazonada es que te falta el permiso de reversión. El indicador -F en su comando implica que zfs rollbackse realizará una y su zfs allowlista no rollback.
En el caso general, se pueden hacer conjeturas deductivas sobre los permisos necesarios para un zfscomando determinado.
La página de manual para zfsseñala:
Los nombres de los permisos son los mismos que los nombres de propiedades y subcomandos de ZFS.
y ...
Los permisos generalmente son la capacidad de utilizar un subcomando ZFS o cambiar una propiedad ZFS. Los siguientes permisos están disponibles:
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
El ejemplo que nos ocupa incluye la -ubandera, por lo que el sistema de archivos no se montará al final de la operación de recepción. Sin embargo, si -uestuviera ausente, el sistema de archivos se montaría al final del proceso de recepción. Es revelador que el receivepermiso requiere el mountpermiso.
Debido a que una zfs mountoperación creará automáticamente los puntos de montaje necesarios, es posible que un usuario tenga zfspermiso para montar el conjunto de datos, pero no tenga permisos del sistema de archivos para crear el punto de montaje. En el caso de zfs mount, el montaje fallará. En una operación zfs createo rename, se creará o se cambiará el nombre del sistema de archivos, pero permanecerá desmontado si el usuario no tiene suficientes permisos del sistema de archivos para crear el punto de montaje.
De manera similar, un zfs renamecomando podría fallar por falta de permisos en varios puntos dentro de la operación de cambio de nombre. En términos generales, los pasos componentes podrían ser:
1) desmontar el sistema de archivos ( mountpermiso)
2) crear un nuevo sistema de archivos ( createpermiso)
3) asignar los metadatos del sistema de archivos al nuevo nombre ( renamepermiso)
Un cuarto paso es volver a montar el sistema de archivos recién nombrado en su nuevo punto de montaje, posiblemente modificado, que nuevamente usa el mountpermiso y posiblemente los permisos del sistema de archivos para crear el nuevo punto de montaje.
No he probado este tipo de trucos, pero se puede ver que zfsdistingue entre permisos createy rename, y también entre permisos mounty mountpoint. Uno imagina que sería posible permitir a un usuario crear nuevos sistemas de archivos, pero una vez creados, el usuario no puede cambiarles el nombre. Para sistemas de archivos con puntos de montaje heredados, cambiar el nombre de un sistema de archivos a menudo también cambiará el nombre del punto de montaje del sistema de archivos, como cuando se cambia el nombre tank/usr/locala tank/usr/local.OLDse cambia el punto de montaje de /usr/locala /usr/local.OLD.
La separación de permisos mountsignifica que a un usuario se le puede permitir cambiar el nombre de un sistema de archivos pero no se le puede permitir cambiar su punto de montaje. O viceversa, poder cambiar dónde está montado un sistema de archivos, pero no poder cambiar el nombre del sistema de archivos.renamemountpoint
La riqueza de las operaciones de su sistema de archivos y la delegación de esas operaciones, junto con la granularidad de los permisos, pueden resultar zfsalgo desafiantes, pero también muy poderosos.
Respuesta2
Parece que tiene una instantánea en la que falta el permiso.
Intente configurar el receivepermiso en neo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03.
Parece que está configurado correctamente en el volumen, pero falta en la instantánea.