web-dev-qa-db-ja.com

LinuxでのNFSv4ACLの使用

NFS HOWTOのセットアップ のガイドに従って、NFSv4クライアントとサーバーを正常にセットアップしました。どちらもUbuntuLinux14.04を実行しています。これは、複雑な認証のない小さなテスト環境です。 2つのサーバーは同じpasswdファイルを使用します。すべてが正しく機能しているようです。ファイルはクライアントに表示され、権限/ユーザーIDは正しいです。

次に、NFSv4 ACLを使用して、NFSv4サーバー上のファイルへのアクセスを制御したいと思います。必要なコマンドラインツールをクライアントにインストールしましたが、NFSv4ACLのようなものを見ることができます。

$ nfs4_getfacl .
A::OWNER@:rwaDxtTcCy
A::GROUP@:rxtcy
A::EVERYONE@:rxtcy

ただし、ACLリストは問題なく取得できますが、ACLを設定することはできません。試行するたびに、setxattrからInvalid argumentエラーが発生します。

$ nfs4_setfacl -a A::OWNER@:rxtncy .
Failed setxattr operation: Invalid argument

Straceを使用して何が起こっているかを確認しました。私が見つけたまばらなドキュメントによると、NFSv4 ACLは、ファイルのsystem.nfs4_aclと呼ばれる拡張属性にバイナリXDRデータとして保存されます。そして確かに、それが起こっていることです。 setxattはEINVALに戻ります。

getxattr("/primary/home/rstudiouser", "system.nfs4_acl", 0x0, 0) = 80
getxattr("/primary/home/rstudiouser", "system.nfs4_acl", "\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x16\x01\xe7\x00\x00\x00\x06OWNER@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa1\x00\x00\x00\x06GROUP@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa1\x00\x00\x00\x09EVERYONE@\x00\x00", 80) = 80
setxattr("/primary/home/rstudiouser", "system.nfs4_acl", "\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa9\x00\x00\x00\x06OWNER@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x16\x01\xe7\x00\x00\x00\x06OWNER@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa1\x00\x00\x00\x06GROUP@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x12\x00\xa1\x00\x00\x00\x09EVERYONE@\x00\x00", 104, XATTR_REPLACE) = -1 EINVAL (Invalid argument)

では、なぜsetxattrが失敗するのですか？拡張属性は、NFSv4サーバーで有効になっています。

$ Sudo tune2fs -l /dev/sda1
tune2fs 1.42.9 (4-Feb-2014)
...
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file 
uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
...

そして、クライアントは確かにNFSv4プロトコルを使用しています。 mountを使用して、マウントされたドライブを表示します。

$ mount
...
192.168.55.103:/primary/home on /primary/home type nfs4 (rw,rsize=8192,wsize=8192,timeo=14,intr,nfsvers=4,acl,addr=192.168.55.103,client
addr=192.168.55.101)
...

Nfsdのすべてのデバッグフラグを反転して、有用なログが生成されるかどうかを確認しました。

$ Sudo rpcdebug -m nfsd -s all

サーバーが属性を設定する要求を受信して​​いることを確認します。

Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567892] nfsd_dispatch: vers 4 proc 1
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567909] nfsv4 compound op #1/2: 22 (OP_PUTFH)
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567915] nfsd: fh_verify(36: 01070001 001c0002 00000000 acf697e6 a847b405 c98a638b)
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567929] nfsv4 compound op ffff88003c2f6080 opcnt 2 #1: 22: status 0
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567932] nfsv4 compound op #2/2: 34 (OP_SETATTR)
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567938] nfsd: fh_verify(36: 01070001 001c0002 00000000 acf697e6 a847b405 c98a638b)
Apr  7 20:21:49 vagrant-ubuntu-trusty-64 kernel: [73465.567978] nfsv4 compound op ffff88003c2f6080 opcnt 2 #2: 34: status 22

「ステータス22」とは何ですか？なぜ、22 = EINVAL、無効な引数、これはsetxattrがクライアントに返すものです。残念ながら、why引数が無効と見なされる理由については何も明らかにされていないようです。

私が試した他のいくつかのこと：

  1. 1つの可能性は、サーバーがACLの形式が正しくないと見なしていることです。これを確認するために、nfs4_setfacl -e .を使用しました。これにより、テキストエディタでexistingACLが開いて操作されます。変更せずにファイルを保存すると、ACLが生成され、適用するとInvalid argumentになります。

  2. ユーザーIDマッピングは、NFSv4のもう1つの一般的な問題です。 NFSv4クライアントの観点から、ユーザーIDが正しく配置されていること、およびファイルの所有権/モードビットが正しいことを検証しました。また、両方のサーバーでDomain = localdomainに/etc/idmapd.confを設定して、NFSv4のドメインを作成しようとしましたが、効果はありません。

LinuxベースのNFSサーバーでNFSv4ACLを使用している場合は、ご意見をお聞かせください。 NFSv4自体をセットアップするためのチュートリアルをたくさん見つけましたが（このティレードの上部にあるリンクを参照）、ACLの使用についてはほとんど言及していません。

linuxubuntupermissionsnfsacl
4
Jonathan

何の価値があるのか​​というと、暗闇の中でさらに数回刺した後、私はついにこの努力をあきらめました。これには、主にZFSでUbuntuホストを試すことが含まれていました。

テスト環境に必要なのはVMで、ACLを備えたNFSv4サーバーを公開できるため、Linuxサーバーを稼働させるための努力を断念し、代わりにFreeBSD10.3イメージを使用することになりました。これをNFSv4で動作させることを試みることはまた困難でしたが、少なくとも可能でした。 nfsv4のFreeBSDマンページ）にはかなりまともなガイドがあります。 （4） 。

1
Jonathan

NFSv4ACLはRichACLに似ています。問題は、RichACLがZFS以外の基盤となるLinuxファイルシステムに実装されていないことです。 Ext4、XFSなどは、前述の限定されたサブセットであるPOSIXACLのみをサポートします。ファイルの実際のアクセス許可は、基盤となるファイルシステムがサポートするものにドロップダウンされます。肝心なのは、ACLはLinuxでは絶対的な混乱であり（まだ2019年3月）、修正する必要があるということです。

0
pgoetz