fossil-scm 1.28 – cannot read repositiory on windows share.

fossil-scm を 1.28にしたところWindowsの共有ドライブに置くrepositoryにいきなりアクセス不能になってしまいました(´・ω・`)

errorは以下のように。

Fossil internal error: read permission denied for repository T:\repos\tools

1.27までは _waccess関数(_access関数の wide文字版) が利用されていたのが、1.28で winfile.c:int win32_access() というファイルの存在やアクセス権限を確認する関数に置き換えられた事が原因っぽい。

対策

原因が読みきれなかったのですが、もともと共有ファイルは

  • 共有を許可しているユーザとグループは サーバ側の特定ローカルアカウントのみ
  • 共有されたファイルのNTFSパーミッションは サーバ側の特定ローカルアカウントのみ

になっていましたので、「共有されたファイルのNTFSパーミッションにBUILTIN\USERSグループを追加」で解決しました。

ソースに手を入れられるなら、簡単にdb.c:db_open_repositoryだったかの関数でwin32_access関数を呼び出しているのを_waccess関数に置き換えてしまう事で治ると思います。

原因

うーん、時間切れで調べきれていません、、、

以下は推測。思考の垂れ流しです。

恐らく、うちの環境が net use \\server\\share /user:server\user と、サーバ側のローカルアカウントとしてnet useしている事が原因と思われます。

win32_access関数はrepositoryファイルの持っているDACLに対して「クライアント側のアカウント」のACEが存在しているかどうかをAccessCheckを使って検証しています。上記の対策前は、repositoryファイルで許可されているのは「サーバ側のアカウント」のみです。

そもそも net useで別アカウントを指定した場合、サーバ側はファイルへのアクセスを ImpersonateLoggedOnUserでログオンしたユーザに偽装した上で行っているんじゃないかと思うので、「サーバにログオンしたユーザに Impersonateしたトークン」でアクセス権限の確認しないとダメなんじゃないかと。

というあたりで時間切れだったので、「共有側でアカウントは制限してるから、NTFS側には BUILTIN\USERSを追加しちゃえばいいか」と安易な解決方法をとってみたところいけました(^^;

時間できたらもう少し確認してみたいなぁ。

Leave a Reply

Your email address will not be published. Required fields are marked *