linux - MercurialACLはプルを防ぎます

Question

ACLと組み合わせたMercurialの背後にあるメカニズムを理解するのを手伝ってください。

私たちのチームは、バージョン管理システムとしてMercurialを使用しています。セットアップは非常に簡単です。2人の開発者（1人のLinux、1人のWindows）、リモートリポジトリ（Linux）です。WindowsユーザーWが変更をチェックインし、LinuxユーザーLが後でプルしたい場合は、次のエラーメッセージ（変更されたファイルによって異なります）が表示されます。

pulling from ssh://user@domain.com
searching for changes
adding changesets
transaction abort!
rollback completed
abort: stream ended unexpectedly (got 0 bytes, expected 4)
remote: abort: Permission denied: /repopath/.hg/store/data/paper/tmp.txt.i

これは、ファイルアクセスがLinuxのACLリストによって処理されるためです。コマンドを使用してACL権限を修正するとsetfacl、すべてがスムーズに実行され、 Lがプルできるようになります。Wが正しい権限でリポジトリを複製したとしても、.hgディレクトリ内の（新規/変更された）ファイルには間違った（デフォルトの）権限があります。リポジトリの親フォルダには正しい権限が設定されているため、それらの権限がどこから継承されているのかわかりません。

誰かが同様の問題に直面しましたか？前もって感謝します！

Answer 1

Linuxボックスでは、グループ権限のスティッキービットを設定する必要がありました。基本的に、Mercurialリポジトリになるディレクトリを作成する場合は、使用する必要があります。chmod g+s <repoDirectory> これにより、そのディレクトリの下に作成されたものはすべて、ファイル作成のデフォルトに関係なく、グループメンバーに対して読み取り/書き込み/実行が強制されます。ACLリストの代わりに標準のUnixグループを使用していたので、これがどのように機能するかわかりません。

Answer 2

.hg/store 内に新しいファイルを作成するとき、Mercurial は.hg/storeディレクトリ自体から (従来の) ファイル許可をコピーし、(@Eric Y のように) スティッキー グループ ビットのようなものでオーバーライドされない限り、書き込みユーザーのユーザー/グループを使用します。これらのファイルのいずれかを変更すると、ユーザーが許可していれば、既存の所有権と権限が保持されますumask。

私の知る限りでは、Mercurial はファイル システム レベルの ACL を特別に処理しません。ほとんどのツールはそうではありません。そのため、ACL システムには継承ルールも含まれています。ディレクトリには独自の ACL があり、そのdefault中に新しく作成されたオブジェクトによって継承される ACLもあります。ディレクトリ -- default ACLACL の設定に加えて、リポジトリの設定を調べる必要があるかもしれません。

そうは言っても、本当に ACL を使用したいですか? すでにそれらを使用していて、それらに精通している場合は素晴らしいですが、Mercurial で 2 ユーザー アクセスを機能させるためだけにそれらを分割した場合は、専用グループ ( などdevelopers) とスティッキー グループ ビットまたは単一の共有 ssh アカウント dev@unixhost を使用し、それぞれに個別の ssh 秘密鍵を使用します (例については、Mercurial wiki の SharedSSH ページを参照してください)。

ACL は非常に強力ですが、ほとんど必要ありません。

他の読者への注意:この質問で私たちが言っていることは、Mercurial の ACL 拡張とは何の関係もありません。それは Mercurial 内にあり、これはファイル システムの ACL レベルのものです。

Answer 3

Debianベースのシステム（Ubuntuなど）のリリースのみがありますが、mercurial-serverを確認する必要があります。Mercurialリポジトリのアクセス制御を柔軟な方法で処理しますが、ファイルシステムACLの外部にあります。