Czasami zachodzi potrzeba udostępnienia ogólnie pojętego zarządzania systemami plików na ZFS-ie zwykłym użytkownikom. Do tej pory istniała tylko możliwość poprzez dopisanie użytkownikowi odpowiedniego profilu (“ZFS File System Management” do zarządzania systemami plików, “ZFS Storage Management” do zarządzania pulami) i uruchamianie polecenia zfs w odpowiednim profilu (poprzez pfexec). Rozwiązanie to ma jednak jedną zasadniczą wadę – dotyczy wszystkich systemów plików ZFS bez możliwości ograniczenia praw użytkownikowi do np. jednego.
Z pomocą przychodzi “ZFS Delegated Administration”, które pojawiło się w OpenSolarisie, build 69 (pełna integracja, w tym poprawiony manual, jest dopiero w buildzie kolejnym). Co to daje? Spróbuję wyjaśnić na przykładzie:
Załóżmy, że mamy następującą pulę:
# zfs list NAME USED AVAIL REFER MOUNTPOINT zpool 121K 66,9G 19K /zpool #
Chcemy stworzyć system plików zpool/pandora, w którym użytkownik dosiu będzie mógł tworzyć i montować nowe filesystemy. Do tego stworzymy również zpool/hydra, gdzie użytkownik ada będzie w stanie tworzyć snapshoty oraz robić ich rollback.
Zatem tworzymy filesystemy:
# zfs create zpool/pandora # zfs create zpool/hydra #
Niestety możliwość montowania systemu plików wymaga odpowiednich uprawnień do katalogu – ustawmy więc dla uproszczenia przykładu po prostu sticky bit (uprawnienia do robienia snapshotów i rollbacku także wymagają uprawnienia do montowania filesystemu):
# chmod 1777 /zpool/{pandora,hydra}
#
I wydelegujmy odpowiednie uprawnienia:
# zfs allow dosiu create,mount zpool/pandora # zfs allow ada snapshot,rollback,mount zpool/hydra #
Sprawdźmy, czy wszystko działa zgodnie z naszymi oczekiwaniami:
dosiu@zfs2.dev:~ $ id uid=100(dosiu) gid=1(other) dosiu@zfs2.dev:~ $ /usr/sbin/zfs list NAME USED AVAIL REFER MOUNTPOINT zpool 188K 66,9G 21K /zpool zpool/hydra 18K 66,9G 18K /zpool/hydra zpool/pandora 18K 66,9G 18K /zpool/pandora dosiu@zfs2.dev:~ $ /usr/sbin/zfs create zpool/pandora/box dosiu@zfs2.dev:~ $ /usr/sbin/zfs create zpool/pandora/medusa dosiu@zfs2.dev:~ $ /usr/sbin/zfs destroy zpool/pandora/medusa cannot destroy 'zpool/pandora/medusa': permission denied dosiu@zfs2.dev:~ $ /usr/sbin/zfs create zpool/hydra/pegasus cannot create 'zpool/hydra/pegasus': permission denied dosiu@zfs2.dev:~ $ /usr/sbin/zfs snapshot zpool/pandora/box@today cannot create snapshot 'zpool/pandora/box@today': permission denied
Czyli dla użytkownika dosiu wszystko jest, jak określiliśmy – ma prawo tworzenia (i montowania) nowych filesystemów w określonej lokalizacji, ale już nie może ich usuwać, czy też tworzyć snapshotów.
ada@zfs2.dev:~ $ id uid=101(ada) gid=1(other) ada@zfs2.dev:~ $ /usr/sbin/zfs create zpool/hydra/head cannot create 'zpool/hydra/head': permission denied ada@zfs2.dev:~ $ /usr/sbin/zfs snapshot zpool/hydra@today ada@zfs2.dev:~ $ touch /zpool/hydra/test_file ada@zfs2.dev:~ $ /usr/sbin/zfs rollback zpool/hydra@today ada@zfs2.dev:~ $ /usr/sbin/zfs destroy zpool/hydra@today cannot destroy 'zpool/hydra@today': permission denied ada@zfs2.dev:~ $ /usr/sbin/zfs list NAME USED AVAIL REFER MOUNTPOINT zpool 242K 66,9G 21K /zpool zpool/hydra 18K 66,9G 18K /zpool/hydra zpool/hydra@today 0 - 18K - zpool/pandora 57K 66,9G 21K /zpool/pandora zpool/pandora/box 18K 66,9G 18K /zpool/pandora/box zpool/pandora/medusa 18K 66,9G 18K /zpool/pandora/medusa ada@zfs2.dev:~ $
I dla użytkownika ada też działa jak potrzeba – może tworzyć snapshoty, robić rollback, ale już na przykład nie jest w stanie wykonać destroy.
Wyświetlanie wydelegowanych uprawnień możliwe jest przez “zfs allow <nazwa/datasetu>, Na przykład:
# zfs allow zpool/hydra
-------------------------------------------------------------
Local+Descendent permissions on (zpool/hydra)
user ada mount,rollback,snapshot
-------------------------------------------------------------
Składnia polecenia jest bardzo bogata (przy zachowaniu jej spójności) – pozwala ustawiać przywileje lokalnie i/lub dla potomnych datasetów w bardzo szerokim zakresie – więcej informacji znajduje się w manualu zfs(1) oraz na blogu Marka Shellenbauma.
Post a Comment