Jak mogę ustalić, jakich uprawnień brakuje mojemu użytkownikowi do otrzymywania zestawu danych ZFS?

9

Mam maszynę FreeNAS (11.1-U1) i FreeBSD (11.1-RELEASE-p6). W FreeNAS chciałbym zfs receiverekursywne migawki jako użytkownik inny niż root z delegowanymi uprawnieniami. Wydaje się, że działa to dobrze w przypadku większości zestawów danych potomnych. Ale datazestawy danych iocage , które można zamontować w więzieniu i administrować stamtąd, zawodzą:

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

Uprawnienia tego konkretnego dziecka są dokładnie takie same jak uprawnienia nadrzędnego zestawu danych:

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

Uruchamianie zfs receivena FreeNAS, ponieważ root działa zgodnie z oczekiwaniami.

Jakich uprawnień delegowanych potrzebuje mój użytkownik do otrzymywania więzionych zestawów danych iocage i, bardziej ogólnie, czy istnieje sposób, aby zfs receivewydać bardziej szczegółowy komunikat o błędzie, który mówi ci, jakich uprawnień brakuje?

sloh
źródło

Odpowiedzi:

3

Podczas rozwiązywania problemów z uprawnieniami wynikającymi z zfspoleceń należy przeanalizować zfsoperację pod kątem kroków składowych.

Przykładowe polecenie zfs receive -duvFrozpakowywania w kilku krokach. Dwie z tych flag nie dotyczą żadnych specjalnych uprawnień:

-d wpływa na nazewnictwo nowego zestawu danych (jeśli istnieje)
-v włącza pełne wyjście

Pozostałe dwa tak.

-F oznacza, że ​​system plików zostanie przywrócony do początkowej migawki przyrostowego transferu przed rozpoczęciem odbioru
-u oznacza, że ​​system plików nie zostanie zamontowany po zakończeniu odbioru

Mam przeczucie, że brakuje Ci uprawnienia do przywracania. Flaga -F w twoim poleceniu oznacza, że zfs rollbackzostanie wykonane, a twoje zfs allownie ma na liście rollback.

W ogólnym przypadku można wywnioskować domysły na temat uprawnień niezbędnych dla danego zfspolecenia.

Strona podręcznika dla zfswskazuje:

Nazwy uprawnień są takie same jak nazwy podkomend i ZFS.

i ...

Uprawnienia to na ogół możliwość korzystania z komendy ZFS lub zmiany właściwości ZFS. Dostępne są następujące uprawnienia:

   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

Podany przykład zawiera -uflagę, więc system plików nie zostanie zamontowany na końcu operacji odbierania. Gdyby jednak -uich nie było, system plików zostałby zamontowany na końcu procesu odbierania. Mówiąc krótko, receivepozwolenie wymaga mountpozwolenia.

Ponieważ zfs mountoperacja automatycznie utworzy wszystkie niezbędne punkty montowania, użytkownik może mieć zfsuprawnienia do montowania zestawu danych, ale nie może mieć uprawnień systemu plików do utworzenia punktu montowania. W przypadku zfs mountmontowania nie powiedzie się. W zfs createlub renameoperacji, system plików zostanie utworzony lub nazwę, ale to pozostanie odmontowana jeśli użytkownik nie ma wystarczających prawa dostępu, aby utworzyć punkt montowania.

Podobnie zfs renamepolecenie może się nie powieść z powodu braku uprawnień w kilku punktach operacji zmiany nazwy. Luźno wyrażone kroki składowe mogą być:

1) odmontuj system plików ( mountpozwolenie)
2) utwórz nowy system plików ( createpozwolenie)
3) zamapuj metadane systemu plików na nową nazwę ( renamepozwolenie)

Czwarty krok polega na ponownym zamontowaniu nowo nazwanego systemu plików w jego nowym, prawdopodobnie zmienionym punkcie montowania, który ponownie korzysta z mountuprawnień i ewentualnie uprawnień systemu plików do utworzenia nowego punktu montowania.

Nie testowałem takich sztuczek, ale widać, że zfsrozróżnia się między nimi createi renameuprawnienia, a także między mounti mountpointuprawnienia. Można sobie wyobrazić, że można zezwolić użytkownikowi na tworzenie nowych systemów plików, ale po utworzeniu użytkownik nie może ich zmienić. W przypadku systemów plików z odziedziczonymi punktami montowania zmiana nazwy systemu plików często powoduje również zmianę nazwy punktu montowania systemu plików, tak jak w przypadku zmiany nazwy tank/usr/localna tank/usr/local.OLDpunkt montowania z /usr/localna /usr/local.OLD.

Oddzielenie uprawnień mountlub renameod mountpointuprawnień oznacza, że ​​użytkownik może mieć możliwość zmiany nazwy systemu plików, ale nie może zmienić jego punktu montowania. Lub odwrotnie, aby móc zmienić miejsce zamontowania systemu plików, ale nie można zmienić nazwy systemu plików.

Bogactwo operacji systemu plików i delegowanie tych operacji, w połączeniu z szczegółowością uprawnień, mogą stanowić zfswyzwanie, ale także bardzo potężne.

Jim L.
źródło
Ta odpowiedź została rozwinięta z oryginału. Mam nadzieję, że nadal będzie zasługiwał na swoje poprzednie głosy poparcia.
Jim L.,
0

Wygląda na to, że masz migawkę, w której brakuje uprawnienia.

Spróbuj ustawić receiveuprawnienia na neo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03.

Wygląda na to, że jest poprawnie ustawiony na woluminie, ale brakuje go na migawce.

Hargut
źródło