Ich habe eine FreeNAS-Maschine (11.1-U1) und eine FreeBSD-Maschine (11.1-RELEASE-p6). Auf der FreeNAS möchte ich zfs receiveals Nicht-Root-Benutzer mit delegierten Berechtigungen rekursive Snapshots erstellen. Dies scheint für die meisten untergeordneten Datensätze gut zu funktionieren. Aber die Datensätze von iocage data, die in das Jail eingebunden und von dort aus verwaltet werden können, schlagen fehl:
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
Die Berechtigungen dieses bestimmten untergeordneten Datensatzes sind genau dieselben wie die des übergeordneten Datensatzes:
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
Das Ausführen zfs receiveauf FreeNAS als Root funktioniert wie erwartet.
Welche delegierten Berechtigungen benötigt mein Benutzer, um die inhaftierten Datasets von iocage zu erhalten, und gibt es allgemeiner eine Möglichkeit, zfs receiveeine detailliertere Fehlermeldung auszugeben, die Sie darüber informiert, welche Berechtigung fehlt?
Antwort1
Analysieren Sie bei der Behebung von Berechtigungsproblemen, die durch zfsBefehle entstehen, den zfsVorgang im Hinblick auf seine einzelnen Schritte.
Der Beispielbefehl zfs receive -duvFentpackt in mehreren Schritten. Zwei dieser Flags beziehen sich nicht auf besondere Berechtigungen:
-d beeinflusst die Benennung des neuen Datensatzes (sofern vorhanden)
-v aktiviert ausführliche Ausgabe
Die anderen beiden schon.
-F bedeutet, dass das Dateisystem vor dem Empfang auf den ursprünglichen Snapshot der inkrementellen Übertragung zurückgesetzt wird.
-u bedeutet, dass das Dateisystem nach Abschluss des Empfangs nicht gemountet wird.
Ich vermute, dass Ihnen die Rollback-Berechtigung fehlt. Das Flag -F in Ihrem Befehl impliziert, dass ein zfs rollbackausgeführt wird, und Ihr zfs allowlistet nicht auf rollback.
Im Allgemeinen kann man deduktive Vermutungen über die für einen bestimmten zfsBefehl erforderlichen Berechtigungen anstellen.
Die Manpage zfsweist darauf hin:
Berechtigungsnamen sind dieselben wie ZFS-Unterbefehls- und Eigenschaftsnamen.
Und ...
Berechtigungen sind im Allgemeinen die Möglichkeit, einen ZFS-Unterbefehl zu verwenden oder eine ZFS-Eigenschaft zu ändern. Die folgenden Berechtigungen sind verfügbar:
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
Das vorliegende Beispiel enthält das -uFlag, sodass das Dateisystem am Ende des Empfangsvorgangs nicht gemountet wird. Wäre es jedoch -unicht vorhanden, würde das Dateisystem am Ende des Empfangsvorgangs gemountet. Bezeichnenderweise receiveerfordert die Berechtigung die mountBerechtigung.
Da bei einem zfs mountVorgang automatisch alle erforderlichen Einhängepunkte erstellt werden, ist es möglich, dass ein Benutzer die zfsBerechtigung zum Einhängen des Datensatzes hat, aber nicht die Dateisystemberechtigungen zum Erstellen des Einhängepunkts. In diesem Fall zfs mountschlägt das Einhängen fehl. Bei einem zfs create- oder rename-Vorgang wird das Dateisystem erstellt oder umbenannt, es bleibt jedoch uneingehängt, wenn der Benutzer nicht über ausreichende Dateisystemberechtigungen zum Erstellen des Einhängepunkts verfügt.
Ebenso zfs renamekann ein Befehl an mehreren Stellen während der Umbenennungsoperation aufgrund fehlender Berechtigungen fehlschlagen. Grob ausgedrückt könnten die einzelnen Schritte sein:
1) Dateisystem aushängen ( mountBerechtigung)
2) neues Dateisystem erstellen ( createBerechtigung)
3) Metadaten des Dateisystems dem neuen Namen zuordnen ( renameBerechtigung)
Ein vierter Schritt besteht darin, das neu benannte Dateisystem an seinem neuen, möglicherweise geänderten Einhängepunkt erneut einzuhängen. Dabei werden erneut die mountBerechtigung und möglicherweise Dateisystemberechtigungen zum Erstellen des neuen Einhängepunkts verwendet.
Ich habe solche Tricks nicht getestet, aber man kann sehen, dass zfszwischen createund renameBerechtigungen und auch zwischen mountund mountpointBerechtigungen unterschieden wird. Man kann sich vorstellen, dass es möglich sein könnte, einem Benutzer das Erstellen neuer Dateisysteme zu erlauben, diese aber nach der Erstellung nicht mehr umbenennen zu können. Bei Dateisystemen mit geerbten Einhängepunkten wird beim Umbenennen eines Dateisystems häufig auch der Einhängepunkt des Dateisystems umbenannt, so wie beim Umbenennen tank/usr/localin tank/usr/local.OLDder Einhängepunkt von /usr/localin geändert wird /usr/local.OLD.
Die Trennung von mountoder renamezu mountpointBerechtigungen bedeutet, dass ein Benutzer ein Dateisystem umbenennen darf, aber nicht seinen Einhängepunkt ändern darf. Oder umgekehrt: Er darf zwar ändern, wo ein Dateisystem eingehängt wird, aber nicht den Namen des Dateisystems.
Die Vielzahl der Dateisystemoperationen und die Delegation dieser Operationen, gepaart mit der Detailliertheit der Berechtigungen, können das Ganze zfsetwas herausfordernd, aber auch sehr leistungsstark machen.
Antwort2
Es sieht so aus, als hätten Sie einen Snapshot, bei dem die Berechtigung fehlt.
receiveVersuchen Sie, die Berechtigung auf festzulegen neo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03.
Auf dem Datenträger scheint es richtig eingestellt zu sein, fehlt aber auf dem Snapshot.