ユーザーがZFSデータセットを受信するために欠落しているアクセス許可をどのように判断できますか？

FreeNAS（11.1-U1）とFreeBSD（11.1-RELEASE-p6）マシンを持っています。FreeNASではzfs receive、委任された権限を持つ非ルートユーザーとして再帰的なスナップショットを作りたいです。これはほとんどの子データセットでうまく機能するようです。しかしdata、刑務所にマウントしてそこから管理できるiocageのデータセットは失敗します。

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

その特定の子の権限は、親データセットの権限とまったく同じです。

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

zfs receiverootとしてFreeNASを実行すると、期待どおりに動作します。

ユーザーは、iocageのjailedデータセットを受け取るためにどの委任された特権を必要としますか。より一般的には、zfs receiveどのアクセス許可が不足しているかを通知する詳細なエラーメッセージを表示する方法はありますか？

zfsコマンドから発生するアクセス許可の問題をトラブルシューティングするときzfsは、コンポーネントの手順の観点から操作を分析します。

zfs receive -duvFいくつかのステップに解凍するサンプルコマンド。これらのフラグのうち2つは、特別な権限とは関係ありません。

-dは新しいデータセット（存在する場合）の命名に影響し
ます-vは詳細な出力を有効にします

他の2つは行います。

-Fは、受信が開始する前
にファイルシステムが増分転送の初期スナップショットにロールバックされることを意味します-uは、受信が完了した後にファイルシステムがマウントされないことを意味します

私の直感は、ロールバックの権限がないことです。コマンドの-Fフラグは、zfs rollbackが実行されることを意味し、はzfs allowリストされませんrollback。

一般的なケースでは、特定のzfsコマンドに必要な権限について演繹的に推測できます。

zfs指摘のmanページ：

権限名は、ZFSサブコマンドおよびプロパティ名と同じです。

そして...

アクセス許可は、通常、ZFSサブコマンドを使用したり、ZFSプロパティを変更したりする機能です。次の権限を使用できます。

   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

手元の例には-uフラグが含まれているため、ファイルシステムは受信操作の最後にマウントされません。ただし、-u存在しない場合、ファイルシステムは受信プロセスの最後にマウントされます。つまり、receive許可には許可が必要mountです。

のでzfs mount操作意志が必要なすべてのマウントポイントを自動作成、ユーザーが持っているため、それが可能であるzfsデータセットをマウントする許可を、しかし、マウントポイントを作成するためのファイルシステム権限を持っていません。の場合zfs mount、マウントは失敗します。ではzfs createまたはrename操作、ファイルシステムが作成または名前の変更が、ユーザがマウントポイントを作成するための十分なファイルシステムの権限を持っていない場合には、アンマウントままになります。

同様に、zfs renameコマンドは、名前変更操作内のいくつかのポイントで権限がないために失敗する可能性があります。大まかに表現すると、コンポーネントのステップは次のようになります。

1）ファイルシステムのマウントを解除する（mount権限）
2）新しいファイルシステムを作成する（create権限）
3）ファイルシステムのメタデータを新しい名前にマッピングする（rename権限）

4番目のステップは、新しく名前が付けられた可能性がある変更されたマウントポイントに新しく名前が付けられたファイルシステムを再マウントすることです。このマウントポイントは、再度mountアクセス許可を使用し、ファイルシステムのアクセス許可を使用して新しいマウントポイントを作成します。

私は、このようなトリックをテストしていませんが、それがあることがわかるzfsとを区別createし、renameアクセス権、およびまたの間mountとmountpoint権限。ユーザーが新しいファイルシステムを作成できるようにすることは可能かもしれませんが、一度作成されると、ユーザーはそれらの名前を変更することはできません。継承されたマウントポイントとファイルシステムについて、また多くの場合、ファイルシステムの名前を変更すると、名前を変更するときのように、ファイルシステムのマウントポイントの名前を変更しますtank/usr/localへのtank/usr/local.OLD変化からマウントポイント/usr/localにします/usr/local.OLD。

分離mountやrenameから、mountpointユーザーがファイルシステムの名前を変更することができますが、そのマウントポイントを変更することはできませんすることができ許可手段。またはその逆で、ファイルシステムがマウントされている場所は変更できるが、ファイルシステムの名前は変更できない。

ファイルシステム操作の豊富さと、それらの操作の委任は、アクセス許可の細分性と相まって、zfsいくらか困難な場合がありますが、非常に強力な場合もあります。

これは、権限がないスナップショットを持っているようです。

にreceive権限を設定してみてくださいneo/backups/freebsd/iocage/jails/owncloud/root/data@2018-03-03。

ボリュームには正しく設定されているようですが、スナップショットにはありません。