2

ファイルが存在するかどうかを検出するには、少なくとも 3 つの手法があります。

  1. ファイル属性を照会する
  2. 検索パターンの代わりに特定のファイル名で FindFile() を使用する
  3. ファイルを読み取りモードで開き、結果のエラーを確認します

上記のすべては、偽陰性に苦しんでいるようです。つまり、実際にはファイルが存在するのに、ネットワーク上の file-io の動作に問題があるか、ファイルのアクセス許可の問題が原因で、ファイルが存在しないと言われます。

ファイルがエクスプローラーに存在することを確認でき、そのファイルを削除できる顧客がいますが、そのファイルを表示しようとすると「アクセスが拒否されました」と表示されます。

この正確な動作を再現することに失敗しました。しかし、作成できるのは、ファイルが存在する状況ですが、アクセス許可が制限されているため、ユーザー資格情報の下にそのフォルダー内のファイルが表示されません。つまり、GetFileAttributes()、FindFile()、および fopen() は失敗を返します。つまり、そのファイルのファイルが見つかりません (しかし、別のアカウント (ネットワーク管理者など) で同じフォルダーを調べると、ファイルが間違いなく存在します）。

私のエンドユーザー（または誰か）がそのような状況でどのようになるかについては、私には不透明です. 私には具体的なアイデアがありません.ファイルが以前に開かれている間に停電が発生した可能性があります.ネットワークの不具合により、ファイルハンドルが外国のPCのデッドプロセスにロックされたままになっている可能性があります...？何がそのような状況を引き起こす可能性があるのか​​ わからないので、私はただものを作っています.

ただし、私が実際に持っていないのは、Windows にクエリを実行して、「ファイル X が存在するかどうか」という事実を知る機能です。

ユーザーのアクセス許可に関係なく、その質問に正直に答える手法を知っている人はいますか (フォルダー自体の内容を照会することが許可されていると仮定します-私は不正アクセスのシナリオを求めていません-単なる「通常の」ユーザー) X はファイル Y を編集できませんが、ファイル Y が存在するかどうかを知りたがっています。

Hokay - これは奇妙になってきています。

2 回尋ねる限り、どのファイル検出手法を使用しても機能します。初めてはいつも「存在しない」と言われます。Second+ は、「はい、そこにありますが、開くことはできません」と教えてくれます。

問題のファイルは、Windows Server 2008 NTFS ドライブの共有フォルダーにあります。全員がフル コントロールで共有されます。顧客の問題をシミュレートするために、手動で「Everyone Deny Read」ACL をファイルに追加しました。したがって、読み取りを拒否しましたが、他のアクセスは拒否し、ファイルのみにアクセスし、共有やこのファイルが存在するフォルダーにはアクセスしませんでした。

(私は自分のソフトウェアやコマンド ライン ユーティリティではなく、Explorer を使用してこの変更を行いました)。

そのサーバーのローカル管理者アカウントからファイルが存在することがわかります。Windows 7で標準ユーザーとしてログインし、UACが有効で、昇格されていないエクスプローラー/アプリケーションであるローカルワークステーションからも存在することがわかりません。

ファイルの読み取りアクセスが明示的に拒否された場合、そのファイルはもはや表示されないように見えます (その拒否が適用されないアカウント、またはアクセスを確認するバックドアの方法を持つローカル管理者を除く)。ファイルにもかかわらず、ACL を拒否します)。

FindFirstFile、GetAttributes、CreateFile、_taccess_s、および PathFileExists を試しました。いずれの場合も、ファイルへの最初のアクセス試行では「ファイルが見つかりません」と表示されますが、2 回目の試行ではエラーは発生しません (ファイルが見つかりました)。

これらの結果を説明し始めることはできません。この時点で、ネットワーク ファイル共有をミックスから削除するために、すべてのテストをローカルで実行する必要があると思います。これらの結果は、（私にとっては）あまり意味がありません。

サーバー上のローカル管理者アカウントからのフォルダーの fltmc 出力:

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
aksdf                                   8       145900         0
luafv                                   1       135000         0
4

4 に答える 4

1

2番目のパラメータを0に設定してCreateFileへのWinAPI呼び出しを試行しましたか？説明は次のとおりです。http：//msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspxおよびパートIが指摘するのは、「このパラメーターがゼロの場合、アプリケーションは、GENERIC_READアクセスが拒否された場合でも、ファイルやデバイスにアクセスせずに、ファイル、ディレクトリ、デバイス属性などの特定のメタデータを照会できます。」

于 2012-07-18T20:29:53.467 に答える
1

これを行うという名前の POSIX 関数がありaccessます。Windows に相当するものがあるようです_access: http://msdn.microsoft.com/en-us/library/1w06ktdy(v=vs.80).aspx

于 2012-06-28T15:34:23.237 に答える
0

シェル関数を使用しますPathFileExists。

FileExists別の方法は、Delphi / BCBの機能を模倣することです。これは、ファイルのFindFirstFile取得に使用してWIN32_FIND_DATA、ファイルが存在するかどうかを確認することです。

ちなみに、あなたが言及している状況は完全に人工的なものです。これは、すべてのデフォルトインストールが非特権ユーザーにさえ割り当てることに関係しSeChangeNotifyPrivilegeています。ユーザー権利は「バイパストラバースチェック」と呼ばれます（[セキュリティ設定]->[ローカルポリシー]->[ユーザー権利の割り当て]の下にあります）:)これは、すべての実用的な目的で、ファイルのパスがわかっていれば、ファイルが存在するかどうかを確認できるはずです。と名前。secpol.msc

そして、はい、ジェリーは正しいです、これはセキュリティホールです。しかし、計算されたもの。特権（「ユーザー権限」）はまさにそれです：特定の許可の問題を無視する方法。これは、Windowsの特権の目的そのものです。

于 2012-06-28T15:39:26.757 に答える
0

「このファイルの名前を見ることさえ許可されていない」という許可が設定されている場合 (たとえば、そのファイルがあるディレクトリへのアクセスが拒否されている場合)、そのファイルを「見る」能力は、その存在を確認または否定するだけでは、明らかなセキュリティ ホールです。

そのため、私が見ることができる可能性はわずかです。最も明白な方法は、管理者アカウントを使用してファイルを検索することです。おそらくユーザーは、管理者アカウントを使用するために資格情報を入力する必要があるため、おそらくユーザーを悩ませるでしょう。管理者アカウントへのアクセス権を持っていないユーザー (たいていの場合) は、まったく機能しません。

もう 1 つの可能性は、実際にはできるはずがないにもかかわらず、やりたいことができるセキュリティ ホールを見つけて悪用することです。これは (少なくとも) 同様に問題があります。ほぼすべての修正プログラム、サービス パックなどが、悪用しているセキュリティ ホールを「塞ぐ」可能性があり、コードが機能しなくなります。同様に、ある種のマルウェア対策ソフトウェアが (多かれ少なかれ正しく) コードが不正であると判断し、悪いことをしているとユーザーに伝える可能性が少なくとも合理的にあります。

于 2012-06-28T15:44:27.473 に答える