問題タブ [file-permissions]

config.Save（ConfigurationSaveMode.Modified）;を呼び出しています。この呼び出しは、WindowsXPでは正常に機能します。

Vistaで実行すると、次のようになります。

例外：System.Reflection.TargetInvocationException：呼び出しのターゲットによって例外がスローされました。---> System.Configuration.ConfigurationErrorsException：構成ファイルのロード中にエラーが発生しました：パス'C：\ Windows \ system32\2lqfj0cv.tmp'へのアクセスが拒否されました。（C：\ Windows \ system32 \ MsiExec.config）---> System.UnauthorizedAccessException：パス'C：\ Windows \ system32\2lqfj0cv.tmp'へのアクセスが拒否されました。

ここで適切な事実は、WindowsインストーラーMSI（マネージDLLへの呼び出し）から上記の呼び出しを実行しているということです。ユーザー権限を上げるために何かする必要があると思いますか？Vistaの権限について本当によく知りませんか？

グループがファイルとサブディレクトリの読み取りと書き込みはできるが、何も削除できないように、ディレクトリのアクセス許可を設定することは可能ですか?

c++ から ACL を変更するには?

確認なしでC ++から次のことを行うのを手伝ってくれる人はいますか:

ここでちょっとわかりにくい質問があります。

必要なもの: ファイル/フォルダーのアクセス許可 (厳密に言えば、DACL の特定の ACE) が継承されているかどうかを判断するには。

これをどのように解決しようとしたか: Python の winapi バインディングを使用する (正確には win32security モジュール)。これは、単純にファイルへのパスを引数として取り、ACE を 1 つずつ出力して、どのフラグが設定されているかを示します。

簡単です。セキュリティ記述子を取得し、そこから DACL を取得してから、DACL 内の ACE を反復処理します。ここで非常に重要なのは、INHERITED_ACE アクセス フラグです。ACE が継承されたときに設定する必要があり、明示的に設定する必要はありません。

フォルダー/ファイルを作成すると、その ACL には、親オブジェクト (フォルダー) の ACE に従って ACE が入力され、子に伝達するように設定されます。ただし、アクセス リストを変更しない限り、INHERITED_ACE フラグは設定されません。ただし、継承されたアクセス許可は存在し、機能します。

わずかな変更 (アクセス リストにエントリを追加し、変更を適用して削除するなど) を行うと、フラグが魔法のように表示されます (動作はまったく変更されませんが、以前は機能し、その後も機能します)。私が望むのは、INHERITED_ACE フラグのこの動作の原因を見つけ、ACE が継承されたかどうかを判断する別の信頼できる方法を見つけることです。

再現方法:

1. オブジェクト (ファイルまたはフォルダー) を作成する
2. Windows エクスプローラーでアクセス許可を確認し、それらが親オブジェクトから伝達されていることを確認します (たとえば、Windows エクスプローラーのファイル プロパティ ダイアログの [セキュリティ] タブを使用します)。
3. たとえば、私が使用していたスクリプトを使用してフラグを確認します (INHERITED_ACE はどの ACE にも設定されません)。
4. オブジェクトの権限を変更 (変更を適用) したり、元に戻したりします。
5. フラグを確認します (INHERITED_ACEがあります)
6. ..信じられないという気持ちで首を横に振る

やや長い投稿で申し訳ありませんが、これが少なくとも少し意味をなすことを願っています.

ASPNET ユーザーに複数のファイルに対するフル コントロールを付与したいのですが、最初にアカウントのトークンを取得する必要があるようです。デスクトップ アプリ内で ASPNET アカウントを偽装する方法を知っている人はいますか?

ありがとう！

Linux のファイルとディレクトリのアクセス許可について少し迷っています。私がやりたいのは、あるユーザーがディレクトリを作成、削除、および名前変更できるようにすることですが、他のユーザーはそうすることができませんが、ディレクトリの読み取りと書き込み、およびそれらのトラバースができる必要があります。

したがって、グループ「ストレージ」はディレクトリ /workspace にアクセスできます。これらのユーザーは、ディレクトリを作成、削除、または名前変更できないと想定されています。グループ「storageAdmin」もディレクトリ /workspace にアクセスできますが、その中のディレクトリを作成、削除、または名前変更することができます。

「storageAdmin」が新しいディレクトリを作成するときは常に、「storage」に自動的にアクセスできるようにして、その中のファイルを読み書きできるようにする必要があります。

これが正しく機能するには、/workspace が「storageAdmin」によって所有され、chmod 775 に設定されている必要があるという点で正しいですか?

NTFSフォルダ（Win2003）へのアクセスを許可して、ファイルがこのフォルダに追加されたときに同じアクセス許可を取得するにはどうすればよいですか？私の問題は、特定のフォルダーの「ネットワークサービス」への読み取りアクセスを許可したが、そのフォルダーにファイルを追加すると（プログラムでこのフォルダーにファイルを生成する）、ネットワークサービスがこれらのファイルへの読み取りアクセス権を持たないことです。パーミッションがフォルダ内のファイルにカスケードされると思いましたか？どんな助けでも大歓迎です。

私の環境では、多数のファイル サーバーで NTFS ACL 監査レポートとさまざまな ACL クリーンアップ アクティビティを実行するプロジェクトがいくつかあります。これらのアクティビティをサーバー上でローカルに実行できない主な理由は 2 つあります。

1) サーバーは実際には別の会社によって所有および管理されているため、サーバーへのローカル アクセス権がありません。

2) それらは変更された Linux OS (GuardianOS と呼ばれる) を実行するSNAP NAS サーバーであるため、ローカル アクセスを取得できたとしても、必要な操作を実行するためのツールが利用できるかどうかはわかりません。

それが邪魔にならないように、私は独自の ACL 監査レポート ツールを展開することになりました。このツールは、指定された最上位パスから始まるファイル システムを再帰的に調べ、ACL で遭遇したすべてのグループ/ユーザーに関する HTML レポートを次のように吐き出します。ツリーをたどる際のアクセス許可の変更を表示するだけでなく、このツールを開発しているときに、ネットワーク オーバーヘッドがこれらの操作を実行する際の最悪の部分であり、プロセスをマルチスレッド化することで、大幅に優れたパフォーマンスを達成できることがわかりました。

ただし、ACL の変更とクリーンアップを実行するための優れたツールを見つけるのにまだ苦労しています。すぐに使用できる標準ツール (cacls、xcacls、Explorer) はシングル スレッドのようで、ネットワーク経由でパフォーマンスが大幅に低下します。マルチスレッド化された独自の ACL 設定プログラムのローリングを見てきましたが、私がよく知っている唯一の API は .NET FileSystemAccessRule のものであり、問​​題は、フォルダーにアクセス許可を設定すると、自動的に「フロー」することです。権限を下げます。マルチスレッドを使用して自分で「流れる」ことをしたいので、これは問題を引き起こします。

NTFS では、継承されたアクセス許可が異なる 2 つの親フォルダー間で同じボリューム上でフォルダー/ファイルが移動され、古いアクセス許可が「継承」されているため、継承されたアクセス許可の一貫性が「許可」されていることはわかっています。

質問

1)現在のフォルダーとすべての子に適用される ACL (標準の「ファイル、フォルダー、およびサブフォルダーに適用」ACL) を設定する方法はありますが、自動的に子オブジェクトに流れないようにする方法はありますか? 基本的には、「はい、この ACL を子オブジェクトに適用する必要がありますが、今のところ、このオブジェクトに直接設定するだけです」と Windows に伝えられるようにしたいと考えています。

明確にするために、「このフォルダーのみ」に適用するための ACL オプションについて知っていますが、要件である継承を失うため、そのオプションは私のユースケースでは有効ではありません。

2) マルチスレッド方式で ACL の変更を実行するための優れたアルゴリズムまたは方法論を知っている人はいますか? 私の直感では、ファイルシステムの再帰的トラバーサルは、特に最上位フォルダーに新しい ACL を定義していて、すべてのサブフォルダーを「クリーンアップ」したい場合は特に、理論的には機能するはずです。最上位に新しい ACL をスタンプしてから、明示的な ACE を削除してから、継承されたアクセス許可を「フロー」ダウンして再帰します。

（参考までに、この質問は、実際にはシステム管理者とプログラミングの問題の両方であるため、ServerFault から部分的に複製されています。他の質問では、ネットワーク経由で高速な ACL 設定を実行できるツールを誰かが知っているかどうかを尋ねていました。）

昨日から、sn.exe を使用するか、sn.exe も使用する Visual Studio を使用して、厳密な名前のキーを生成できませんでした。

キーファイルを生成しようとすると、次のシマンドが実行されます

sn - k "鍵ファイル.snk"

sn.exe は、次のように応答します。

厳密な名前のキー ペアを生成できませんでした -- アクセスが拒否されました。

Process Monitor の実行中にこのプロセスを繰り返した後、sn.exe がアクセスを拒否された場所はすべて次のディレクトリ内にあることがわかりました。

\ProgramData\Microsoft\Crypto\RSA\MachineKeys

このフォルダの権限を照会すると、Everyone および Administrators グループには権限がなく、NETWORK SERVICE アカウントにはフル コントロールがあることがわかります。

昨日、NETWORK SERVICE アカウントを使用する SourceGear Fortress をインストールしましたが、問題が発生する前のシステムへの重要な変更はこれだけでした。

Everyone と Administrators が RSA キー ストアに対する権限を持たないのは正常ですか?