web-dev-qa-db-ja.com

NFSv4がPOSIXACLを使用可能な方法で変換しないのはなぜですか？

一部のフォルダー（モード設定を使用）にパブリックアクセス権がなく、グループ所有者が読み取り専用特権を持っているXFSファイルシステムがあります。すべてのファイルへの読み取りアクセスを必要とするプログラム（ユーザーcryosparc_userとして実行される）があるため、cryosparc_userに読み取りアクセスを許可するデフォルトのPOSIXACLを追加しました。

残念ながら、ほとんどの処理は、NFSv4がこのファイルシステムをマウントするワークステーションで実行され、何らかの理由でPOSIX ACLがワークステーションで変換または尊重されていません（まあ、そうですが、明らかに使用可能な方法ではありません）。理由がわかりません。

サーバーとワークステーションの両方がUbuntu18.04を実行しています。グループは、Active Directoryセキュリティグループ（ADを介して認証を行っています）であり、cryosparc_userはできないローカルユーザーであるため、単純にcryosparc_userをグループに追加することはできません。 ADで設定されます。

ファイルサーバーの権限は次のとおりです。

root@kraken:/EM/EMtifs# getfacl pgoetz
# file: pgoetz
# owner: pgoetz
# group: cns-cnsitlabusers
user::rwx
group::r-x
other::---
default:user::rwx
default:user:cryosparc_user:r-x
default:group::r-x
default:mask::r-x
default:other::---

root@kraken:/EM/EMtifs# id cryosparc_user
uid=1017(cryosparc_user) gid=1017(cryosparc_user) groups=1017(cryosparc_user),10002(mclellan),10003(taylorlab)

NFSv4マウントを使用したワークステーションでの外観は次のとおりです。

root@javelina:/EM/EMtifs# getfacl pgoetz
# file: pgoetz
# owner: pgoetz
# group: cns-cnsitlabusers
user::rwx
group::r-x
other::---

root@javelina:/EM/EMtifs# id cryosparc_user
uid=1017(cryosparc_user) gid=1017(cryosparc_user) groups=1017(cryosparc_user)

root@javelina:/EM/EMtifs# nfs4_getfacl pgoetz
A::OWNER@:rwaDxtTcCy
A::GROUP@:rxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:1017:rxtcy
A:fdi:GROUP@:rxtcy
A:fdi:EVERYONE@:tcy

NFS4ACLクエリの下から3行目に注目してください。ただし、cryosparc_userユーザーには読み取りアクセスが許可されているようです（ローカルUIDは両方のシステムで1017です）。

cryosparc_user@javelina:/EM/EMtifs$ whoami
cryosparc_user
cryosparc_user@javelina:/EM/EMtifs$ ls pgoetz
ls: cannot open directory 'pgoetz': Permission denied

私が読んだすべてのことから、設定するマウントフラグやこのようなものはありません。これは自動的に機能するはずで、なぜ機能しないのか理解できません。

私のフォールバックプランは、これらのフォルダーでローカルグループを使用するように戻すことです（cryosparc_userをローカルグループに追加できるようにするため）が、これには各システムでAD認証構造を複製する必要があり、メンテナンスの頭痛の種になります。

別のアイデアは、マウントにcryosparc_userユーザー資格情報を使用してこのファイルシステムの読み取り専用SMBマウントを行うことでもありましたが、500Tファイルシステムをダブルマウントすることにもそれほど興奮していません。 dむしろ、認証は合理的な方法で機能します。

linuxaclxfsnfsv4
1
pgoetz

私の問題は、POSIXACLがどのように機能するかを理解できないことであることが判明しました。特に、デフォルト ACLは、適用されたディレクトリにアクセス許可を設定すると想定しましたが、実際には、これらはデフォルトACLの後に作成されたサブディレクトリとファイルにのみ適用されます。親オブジェクトに適用されており、実際には親オブジェクトをまったく適用していません。

私をひっくり返したのは、この問題に関するNFS開発者リストの魅力でした。開発者の1人は、NFSはこれについて完全に不可知論的であり、サーバーの基盤となるファイルシステムに設定されたアクセス許可に単にアピールすることを指摘しました（そしてこれを知ることは重要です）。これは、サーバーファイルシステム上のPOSIX ACLを調べる方向を示し、いくつかの実験の後（これは十分に文書化されていません）、上記の機能を実現し、POSIX ACLを再作成して、実際に実行したいことを実行しました。 。その後、問題は解決しました。

1
pgoetz

POSIXACLと呼ばれる可能性のあるものは存在しません。

Aproxから標準的な提案案がありました。ユーザーがこの種のACL実装を好まなかったため、1997年に撤回された1993年。

存在するACLの唯一の標準はNFSv4です。

NFSv4ACLをサポートする最新のオペレーティングシステムを使用してみてください。

1
schily