Eu tenho uma máquina FreeNAS (11.1-U1) e uma máquina FreeBSD (11.1-RELEASE-p6). No FreeNAS, gostaria de fazer zfs receivesnapshots recursivos como um usuário não root com privilégios delegados. Isso parece funcionar bem para a maioria dos conjuntos de dados filhos. Mas dataos conjuntos de dados do iocage, que podem ser montados na prisão e administrados a partir daí, falham:
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
As permissões desse filho específico são exatamente as mesmas do conjunto de dados pai:
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
Executar zfs receiveno FreeNAS como root funciona conforme o esperado.
De quais privilégios delegados meu usuário precisa para receber os conjuntos de dados presos do iocage e, de maneira mais geral, existe uma maneira de emitir zfs receiveuma mensagem de erro mais detalhada informando qual permissão está faltando?
Responder1
Ao solucionar problemas de permissão decorrentes de zfscomandos, analise a zfsoperação em termos de etapas do componente.
O comando de exemplo de zfs receive -duvFdescompacta em várias etapas. Dois desses sinalizadores não estão relacionados a nenhuma permissão especial:
-d afeta a nomenclatura do novo conjunto de dados (se houver)
-v ativa a saída detalhada
Os outros dois sim.
-F significa que o sistema de arquivos será revertido para o instantâneo inicial da transferência incremental antes do início do recebimento
-u significa que o sistema de arquivos não será montado após o término do recebimento
Meu palpite é que você está perdendo a permissão de reversão. O sinalizador -F em seu comando implica que a zfs rollbackserá executado e seu zfs allownão lista rollback.
No caso geral, pode-se fazer suposições dedutivas sobre as permissões necessárias para um determinado zfscomando.
A página de manual para zfsaponta:
Os nomes das permissões são iguais aos nomes dos subcomandos e das propriedades do ZFS.
e ...
As permissões geralmente são a capacidade de usar um subcomando do ZFS ou alterar uma propriedade do ZFS. As seguintes permissões estão disponíveis:
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
O exemplo em questão inclui o -usinalizador, portanto o sistema de arquivos não será montado no final da operação de recebimento. Porém, se -uestivesse ausente, o sistema de arquivos seria montado no final do processo de recebimento. Notavelmente, a receivepermissão requer a mountpermissão.
Como uma zfs mountoperação criará automaticamente quaisquer pontos de montagem necessários, é possível que um usuário tenha zfspermissão para montar o conjunto de dados, mas não tenha permissões de sistema de arquivos para criar o ponto de montagem. No caso de zfs mount, a montagem falhará. Em uma operação zfs createou rename, o sistema de arquivos será criado ou renomeado, mas permanecerá desmontado se o usuário não tiver permissões de sistema de arquivos suficientes para criar o ponto de montagem.
Da mesma forma, um zfs renamecomando pode falhar por falta de permissões em vários pontos da operação de renomeação. Expressas livremente, as etapas do componente podem ser:
1) desmontar o sistema de arquivos ( mountpermissão)
2) criar um novo sistema de arquivos ( createpermissão)
3) mapear os metadados do sistema de arquivos para o novo nome ( renamepermissão)
Uma quarta etapa é remontar o sistema de arquivos recém-nomeado em seu novo ponto de montagem possivelmente alterado, que novamente usa a mountpermissão e possivelmente as permissões do sistema de arquivos para criar o novo ponto de montagem.
Não testei esses truques, mas pode-se ver que zfsdistingue entre createe renamepermissões, e também entre mounte mountpointpermissões. Imagina-se que seja possível permitir que um usuário crie novos sistemas de arquivos, mas uma vez criados, o usuário não poderá renomeá-los. Para sistemas de arquivos com pontos de montagem herdados, renomear um sistema de arquivos geralmente também renomeará o ponto de montagem do sistema de arquivos, como ao renomear tank/usr/localpara tank/usr/local.OLDaltera o ponto de montagem de /usr/localpara /usr/local.OLD.
A separação de mountou renamede mountpointpermissões significa que um usuário pode ter permissão para renomear um sistema de arquivos, mas não pode alterar seu ponto de montagem. Ou vice-versa, para poder alterar onde um sistema de arquivos está montado, mas não poder alterar o nome do sistema de arquivos.
A riqueza de suas operações de sistema de arquivos e a delegação dessas operações, juntamente com a granularidade das permissões, podem torná-lo zfsum tanto desafiador, mas também muito poderoso.
Responder2
Parece que você tem um instantâneo onde falta a permissão.
Tente ativar a receivepermissão neo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03.
Parece que está configurado corretamente no volume, mas está faltando no instantâneo.