2

至少有三种技术可以检测文件是否存在：

  1. 查询文件属性
  2. 使用具有特定文件名而不是搜索模式的 FindFile()
  3. 以读取模式打开文件并查看任何导致的错误

以上所有似乎都受到假阴性的影响。也就是说，我被告知该文件实际上不存在，这是由于网络上的 file-io 工作方式出现故障，或者由于文件权限问题。

我有一个客户可以看到资源管理器中存在一个文件，删除该文件，但如果他们尝试查看该文件，则会被“拒绝访问”。

我未能成功复制这种确切的行为。但是我可以创建的是文件存在的情况，但是由于限制了对它的权限，我无法在我的用户凭据下看到该文件夹​​中的文件。也就是说，GetFileAttributes()、FindFile() 和 fopen() 返回失败，即找不到该文件的文件（但如果我在不同的帐户下查看同一个文件夹 - 比如说网络管理员，我可以看到该文件肯定存在）。

至于我的最终用户（或任何人）将如何在这种情况下结束对我来说是不透明的。我没有具体的想法 - 可能是之前打开文件时出现电源故障，可能是某种网络故障导致文件句柄保持锁定到外国 PC 上的死进程，...？我只是在编造一些东西，因为我不知道是什么导致了这种情况的出现。

但是，我真正没有的是能够查询 Windows 并知道“文件 X 是否存在”这一事实

有谁知道一种技术可以诚实地回答这个问题而不管用户的权限如何（假设他们被允许查询文件夹本身的内容 - 我不是在要求未经授权的访问场景 - 只是一个“普通”用户X 无法编辑文件 Y，但仍想知道文件 Y 是否存在。

Hokay - 这越来越奇怪了。

只要我问两次，就可以使用任何文件检测技术。第一次总是告诉我“不存在”。Second+ 告诉我“是的，它在那里，但你无法打开它。”

有问题的文件位于 Windows Server 2008 NTFS 驱动器上的共享文件夹中。它是共享给每个人完全控制的。为了模拟我的客户问题，我手动向文件中添加了“Everyone Deny Read”ACL。因此，我拒绝了读取，但没有其他访问权限，并且只能访问该文件，而不是共享或该文件所在的文件夹。

（我使用资源管理器进行此修改，而不是我自己的软件或命令行实用程序）。

我可以看到该文件存在于该服务器上的本地管理员帐户中。我什至看不到它存在于我的本地工作站，在 Windows 7 下以标准用户身份登录，启用 UAC，非提升的资源管理器/应用程序。

看起来，如果文件的读取访问权限被明确拒绝，则该文件将不再可见（除非该拒绝不适用的帐户，或者具有某种后门方式查看文件的本地管理员）文件尽管拒绝 ACL）。

我尝试过 FindFirstFile、GetAttributes、CreateFile、_taccess_s 和 PathFileExists。在每种情况下，第一次访问文件的尝试都指示“找不到文件”，但连续第二次尝试会导致无错误（找到文件）。

我无法开始解释这些结果。我认为此时我需要在本地运行所有测试，以从混合中删除网络文件共享。这些结果并没有使整个 heckuva 很有意义（对我来说）。

文件夹的 fltmc 输出，来自服务器上的本地管理员帐户：

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

4 回答 4

1

您是否尝试过 WinAPI 调用 CreateFile 并将第二个参数设置为 0 ？这里的描述： http: //msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx我指向你的部分是：“如果这个参数是零，应用程序可以查询某些元数据，例如文件、目录或设备属性，而无需访问该文件或设备，即使 GENERIC_READ 访问被拒绝。”

于 2012-07-18T20:29:53.467 回答
1

有一个名为 POSIX 的函数access可以做到这一点。看起来有一个 Windows 等价物：http _access: //msdn.microsoft.com/en-us/library/1w06ktdy (v=vs.80).aspx

于 2012-06-28T15:34:23.237 回答
0

使用外壳功能PathFileExists。

另一种方法是模仿FileExistsDelphi/BCB 中的做法，即FindFirstFile用来获取WIN32_FIND_DATA文件的文件，从而检查它是否存在。

顺便说一句，你提到的情况完全是人为的。SeChangeNotifyPrivilege它与每个默认安装分配给非特权用户的内容有关。用户权限称为“绕过遍历检查”（在安全设置 -> 本地策略 -> 用户权限分配下）:) 这意味着，出于所有实际目的，如果您知道文件的路径secpol.msc，您应该能够找出文件是否存在和名字。

是的，杰瑞是对的，这是一个安全漏洞。而是经过计算的。权限（“用户权限”）就是这样：一种忽略某些权限问题的方法。这是 Windows 中特权的目的。

于 2012-06-28T15:39:26.757 回答
0

如果权限设置为“您甚至不允许查看此文件的名称”（例如，拒绝您访问它所在的目录），则任何“查看”该文件的能力，即使达到仅仅确认或否认它的存在就是一个明显的安全漏洞。

因此，我只能看到几种可能性。最明显的是使用管理员帐户来搜索文件。这可能会惹恼用户，因为他们很可能需要输入该管理帐户的凭据才能使用它。对于无权访问管理员帐户的用户（您希望大多数情况下），它根本不起作用。

另一种可能性是找到并利用一个安全漏洞，让你做你想做的事，即使你真的不应该做。这（至少）同样有问题——几乎任何修补程序、服务包等都可能“堵塞”您正在利用的安全漏洞，并且您的代码将停止工作。同样，至少有一个合理的机会，某种反恶意软件可能会决定（或多或少正确地）您的代码很顽皮，并告诉用户它正在做坏事。

于 2012-06-28T15:44:27.473 回答