Podczas rozwiązywania problemów z uprawnieniami wynikającymi z zfs
poleceń należy przeanalizować zfs
operację pod kątem kroków składowych.
Przykładowe polecenie zfs receive -duvF
rozpakowywania 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 rollback
zostanie wykonane, a twoje zfs allow
nie ma na liście rollback
.
W ogólnym przypadku można wywnioskować domysły na temat uprawnień niezbędnych dla danego zfs
polecenia.
Strona podręcznika dla zfs
wskazuje:
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 -u
flagę, więc system plików nie zostanie zamontowany na końcu operacji odbierania. Gdyby jednak -u
ich nie było, system plików zostałby zamontowany na końcu procesu odbierania. Mówiąc krótko, receive
pozwolenie wymaga mount
pozwolenia.
Ponieważ zfs mount
operacja automatycznie utworzy wszystkie niezbędne punkty montowania, użytkownik może mieć zfs
uprawnienia do montowania zestawu danych, ale nie może mieć uprawnień systemu plików do utworzenia punktu montowania. W przypadku zfs mount
montowania nie powiedzie się. W zfs create
lub rename
operacji, 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 rename
polecenie 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 ( mount
pozwolenie)
2) utwórz nowy system plików ( create
pozwolenie)
3) zamapuj metadane systemu plików na nową nazwę ( rename
pozwolenie)
Czwarty krok polega na ponownym zamontowaniu nowo nazwanego systemu plików w jego nowym, prawdopodobnie zmienionym punkcie montowania, który ponownie korzysta z mount
uprawnień i ewentualnie uprawnień systemu plików do utworzenia nowego punktu montowania.
Nie testowałem takich sztuczek, ale widać, że zfs
rozróżnia się między nimi create
i rename
uprawnienia, a także między mount
i mountpoint
uprawnienia. 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/local
na tank/usr/local.OLD
punkt montowania z /usr/local
na /usr/local.OLD
.
Oddzielenie uprawnień mount
lub rename
od mountpoint
uprawnień 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ć zfs
wyzwanie, ale także bardzo potężne.
Wygląda na to, że masz migawkę, w której brakuje uprawnienia.
Spróbuj ustawić
receive
uprawnienia naneo/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.
źródło