8

私たちのアプリは、実行可能ファイルのあるディレクトリにライセンスファイルを必要とするコンポーネントを使用しています。これはたまたま.NET WinFormsアプリですが、この質問には重要ではないと思います。一部のXPProマシン（これまでの数百台のうち3台）にインストールすると、コンポーネントはライセンス例外をスローします。そこで、ライセンスファイルを再生成して、コンポーネントベンダー（EMC Captiva）に送信しました。ベンダーは、「Users」グループにファイルの読み取り権限がないためにエラーが発生したと主張しています。エラーが発生したユーザーはたまたまローカル管理者ですが、もっと一般的な質問に興味があるので、それは重要ではありません。

だから私の質問は、特にライセンスファイルが私の開発マシン（マシン1）で生成され、Subversion（マシン2）に保存され、ソース管理からチェックアウトされたときに、ACLがその存続期間中ファイルに従うようにファイルに保存されているかどうかですTeamCity（マシン3）によって、InstallShield（マシン4）によってインストーラーにパッケージ化され、最終的に管理者によってインストールされた顧客のマシン（マシン5）にデプロイされましたか？開発マシン（マシン1）でファイルを生成し、サポートサイト（マシン2）を介してコンポーネントベンダーにアップロードし、サポート担当者が検査のためにファイルをマシン（マシン3）にダウンロードした後はどうでしょうか。

これは確かにわかりませんが（これがここで質問している理由です）、各Windowsマシンは、ファイル内ではなく、NTFSによって管理される中央ディレクトリ/リスト/テーブルにACLを格納すると想定しました。元のファイルのACLは、あるマシンから別のマシンにコピーされたり、Subversionに保存されたり、MSIにパッケージ化されたりするとどうなりますか？誰かが私にこれについて読むことができるいくつかの良い参考文献を教えてもらえますか？

4

1 に答える 1

15

ACLは、すべてのバックグラウンド配管を行うNTFSパーティションの一部であるMFT（マスターファイルテーブル）に格納されます。

ACLはファイルの一部ではないため（ファイル名と同様にメタデータであるため）、周囲のファイルを追跡しません。ファイルはパーティションタイプの境界を越えることができます（NTFS-> FAT）が、ACLはできません。

これで、1つのNTFSパーティション内でファイルを移動すると、ACLが実際にファイルを追跡しているように見える場合があります。これは、移動中にMFTのファイル名のみが実際に変更されるためです。他のすべては同じままです。

ファイルをコピーするか、別のパーティションまたはコンピューターに移動すると（実際にはコピーと削除の操作です）、コピーされたファイルはデフォルトで新しいコンテナーのアクセス許可を継承します（正確には継承可能なコンテナーのみ）。

ただし、パーティションやコンピューターの境界を越えても、コピー操作後にファイルのACLを保持できるツールがあります（コピー操作後にターゲットファイルにACLを再作成するだけです）。xcopyは、とりわけそれを行うことができます。

ただし、ACLには「ドメイン所有」のSIDを含めることができるため、ACLエントリは、同じドメインの一部ではないターゲットコンピュータにとって実際には意味がない場合があります（たとえば、NTFS形式のUSBドライブを持ち帰る場合）。その場合、ACLエントリは効果がありません。

他のSIDは、「SYSTEM」SIDのように「よく知られている」ものです。これらは実際にはドメインの境界を越えて認識されます。

于 2009-05-08T12:53:14.727 に答える