it-swarm-ja.com

書き込み権限を持つユーザーのnfs共有を設定する方法

LDAP認証を使用するデスクトップでubuntulinuxを使用しました。サーバーとクライアントの両方で、同じユーザーとグループがあります。

パブリック共有を使用してnfsサーバーをセットアップしました。これは、書き込み権限を持つすべてのユーザーが利用できるはずです。たとえば、1人のユーザーが作成したファイル、他のユーザーはデフォルトでこのファイルを削除できます。

次の要件があります。

  1. クライアントマシンのデフォルトのumask(0022)を変更したくありません。
  2. サーバー上でファイルが変更されたときに変更権限にinotifyを使用したくないのは、nfs共有を使用したネットワークアクセスが遅くなり、安定して動作しないためです。

再現方法:

私は、フォルダの次の権限を持つデフォルトのACLで初期フォルダを作成しますディレクトリグループが所有inoffice

$ setfacl -m default:g:inoffice:rwx directory/
$ setfacl -m g:inoffice:rwx directory/
$ getfacl directory/

# file: directory/
# owner: root
# group: root
user::rwx
group::r-x
group:inoffice:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:inoffice:rwx
default:mask::rwx
default:other::r-x

理論的には:1。このディレクトリは、グループinofficeのユーザーが書き込み可能である必要があります。 2.すべての新しいファイルとディレクトリはgroup:inoffice:rwx権限を継承します

2人のユーザー(クライアント)がいるとします。

user1 with primary group __USERS__ and supplementary group inoffice 
user2 with primary group __USERS__ and supplementary group inoffice 

User1が自分のマシンのnfsフォルダーdirectoryに移動し、「folder_user1」という名前のフォルダーを作成したとします。

getfacl folder_user1
# file: folder_user1
# owner: user1
# group: user1_group
user::rwx
group::r-x
group:inoffice:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:inoffice:rwx
default:mask::rwx
default:other::r-x

その後、user2はdefault:group:inoffice:rwx権限のためにこのフォルダを削除できます

ただし、user1がディレクトリを(作成する代わりに)ディレクトリにコピーする場合。結果の権限は次のようになります。

$ getfacl folder_copied_by_user1
# file: folder_copied_by_user1
# owner: user1
# group: user1_group
user::rwx
group::r-x
group:inoffice:rwx      #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:inoffice:rwx
default:mask::rwx
default:other::r-x

Linuxでファイルをコピーして作成するときのopenメソッドの呼び出しの違いを知っています。また、ファイル作成操作後に適用されるumaskについても知っています。

私の場合、nfsプロトコルを使用してネットワーク上でファイルを共有するための解決策が見つかりません。

回避策を見つけるのを手伝ってください。

2
vskubriev

私はこれで簡単な回避策を見つけました 記事

ユーザーごとに個別のプライマリグループを使用する場合は、umask = 002を使用できます。そうすると、グループのアクセス許可がumaskによって切断されなくなります。また、setgidまたはaclを使用してアクセス許可を設定できます。

しかし、提案されたソリューションは、ユーザーの管理、つまり作成と削除を複雑にします。 LDAP管理者であるため、すべてのLDAPユーザーのプライマリグループを作成する必要があります。不要なユーザーを削除する場合は、プライマリユーザーのグループを削除します。

さらに、私は注意します:

Openldapのzentyalからの移行により、新しく作成されたすべてのユーザーに同じコアグループ([〜#〜] users [〜#〜])を使用します。

一方では、ユーザーの管理が簡素化されますが、他方では、ユーザーの共有フォルダーの問題は解決されませんでした。

0
vskubriev