2

There are at least three techniques for detecting if a file exists:

  1. Query the file attributes
  2. Use FindFile() with a specific filename instead of a search pattern
  3. Open the file in read mode and look at any resulting error

All of the above seem to suffer from false negatives. That is, I am told that the file doesn't exist when it actually does due to either glitches in how file-io over a network works, or due to file permissions issues.

I have a customer who can see that a file exists in explorer, delete that file, but is given "access denied" if they try to view that file.

I have been unsuccessful at replicating this exact behavior. But what I can create is a situation where the file exists, but due to restricting permissions on it, I cannot see the file in that folder under my user credentials. That is, GetFileAttributes(), FindFile(), and fopen() return failure, i.e. file not found for that file (but if I look in that same folder under a different account - say a network admin, I can see that the file most certainly exists).

As to how my end user (or anyone) would end up in such situations is opaque to me. I have no concrete ideas - maybe power failure while the file was previously opened, maybe some sort of network glitch causing the file handle to remain locked to a dead process on a foreign PC, ...? I'm just making stuff up because I have no idea what might cause such situations to arise.

However, what I really don't have is the ability to query Windows and know for a fact "does file X exist, or not"

Does anyone know of a technique that will honestly answer that question regardless of the user's permissions (assuming that they're allowed to query the contents of the folder itself - I'm not asking for an unauthorized access scenario - just a "normal" user X can't edit file Y, but still wants to know if file Y exists or not.

Hokay - this is getting bizarre.

Using any of the file detection techniques works so long as I ask twice. The first time always tells me "does not exist". Second+ tells me "yup, it's there, but you can't open it."

The file in question is on a shared folder on a Windows Server 2008 NTFS drive. It is shared for everyone full control. I have manually added an "Everyone Deny Read" ACL to the file, in order to simulate my customers problem. So I have denied read, but no other access, and only to the file, not to the share, or the folder in which this file lives.

(I used Explorer to make this modification, not my own software or a command line utility).

I can see that the file exists from the local admin account on that server. I cannot see that it even exists from my local workstation, logged in as a standard user under Windows 7, UAC enabled, non-elevated explorer / application.

It would appear that if a file's read-access is explicitly denied, that the file is not visible any longer (except to account for which that deny doesn't apply, or to the local admin which has some back-door way to see the file despite that deny ACL).

I have tried FindFirstFile, GetAttributes, CreateFile, _taccess_s, and PathFileExists. In every case, the first attempt to access the file indicates "file not found", but the second attempt in a row results in no-error (file found).

I cannot begin to explain these results. I think at this point I need to run all of my tests locally, to remove network file sharing from the mix. These results just don't make a whole heckuva lot of sense (to me).

fltmc output for the folder, from local admin account on the server:

Filter Name Num Instances Altitude Frame ------------------------------ ------------- ------------ ----- aksdf 8 145900 0 luafv 1 135000 0
Improve this question
7
  • What version of windows are we talking here. The user may need to run as administrator or run as userxxx. Commented Jun 28, 2012 at 15:37
  • Also, have you looked here msdn.microsoft.com/en-us/library/… Commented Jun 28, 2012 at 15:38
  • I don't want the user to do impersonations, or our software to have to do anything of the sort. I just want "for standard users, a way to detect if a file exists in a folder, even if they don't have read/write permissions on said file." Commented Jun 28, 2012 at 15:38
  • 1
    If they don't have read permissions on the file or the path to the file, then they don't have permission to know the file exists ie unauthorized access Commented Jun 28, 2012 at 15:40
  • @8bitwide: this is not the full story. Please read up on SeChangeNotifyPrivilege :) Commented Jun 28, 2012 at 16:25

4 Answers 4

Reset to default
1

There's a POSIX function named access that does this. It looks like there's a Windows equivalent _access: http://msdn.microsoft.com/en-us/library/1w06ktdy(v=vs.80).aspx

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

This works! It actually tells me, with user permissions, about the existence of the file (at least under the contorted test scenario I'm using to approximate my customer's issue). It is of limited value due to the fact that further calls to attempt to access the file fail with an effective "file not found" error, so confuses downstream code. This may be just much of an edge case to handle gracefully in a generic way...
UPDATE: This is even more bizarre: if I check the file once, I get ENOENT (i.e. file not found). But if I check a second (or subsequent times), I get status 0, or file exists. :(
1

have You trie WinAPI call to CreateFile with second parameter set to 0 ? Here's description: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx and part I point You to is: "If this parameter is zero, the application can query certain metadata such as file, directory, or device attributes without accessing that file or device, even if GENERIC_READ access would have been denied."

Improve this answer

Comments

0

If permissions are set up to say "you're not allowed to even look at the name of this file" (e.g., denied you access to the directory it's in), any ability to "see" that file, even to the extent of just confirming or denying its existence is a clear security hole.

As such, there are only a few possibilities that I can see. The most obvious would be to use an Administrator account to search for the file. This will probably annoy the user, as they'll most likely need to enter credentials for that administrative account to use it. For users who don't have access to an Administrator account (most, you'd hope) it simply won't work at all.

Another possibility would be to find and exploit a security hole that lets you do what you want, even though you're really not supposed to be able to. This is (at least) equally problematic -- nearly any hotfix, service pack, etc., might "plug" the security hole you're exploiting, and your code will quit working. Likewise, there's at least a reasonable chance that some sort of anti-malware software might decide (more or less correctly) that your code is being naughty, and tell the user it's doing bad things.

Improve this answer

3 Comments

Sort of duplicating, but I'm not aware of what permission in Windows maps to "hide the existence of this file"?
@Mordachai: Directories have permissions. Denial of access to a directory hides the existence of all files in that directory. One minor extra detail: in default configuration, Windows doesn't check the permissions on all directories in the path though, so given a path like "C:\a\b\c.txt", a denial in a's ACL won't usually prevent access to c.txt, though it will only be accessible via foreknowledge of the path (i.e., the user won't be able to browse to it). Windows can be configured to check the whole path, if desired though.
That's my understanding as well. But in this case, I'm just talking about a single file in a folder that is executable (traversable). So the user has permissions to list the dir, can see other files, but one file is "invisible" (and not due to 'hidden' attribute). I am able to see the file as local admin, just not as a standard user. But standard users can see all other files. I was unaware (and remain so) as to what permission exactly controls such per-file-visibility?
0

Use the shell function PathFileExists.

An alternative is to mimic what FileExists in Delphi/BCB does, which is to employ FindFirstFile to get the WIN32_FIND_DATA of the file and thus check whether it exists or not.

And by the way, the situation you refer to is completely artificial. It relates to SeChangeNotifyPrivilege which every default installation assigns to even unprivileged users. The user right is called "bypass traverse checking" (in secpol.msc under Security Settings -> Local Policies -> User Rights Assignment) :) It means that for all practical purposes you should be able to find out if a file exists if you know its path and name.

And yes, Jerry is right, this is a security hole. But a calculated one. Privileges ("user rights") are exactly that: a way to ignore certain permission issues. It's the very purpose of privileges in Windows.

Improve this answer

4 Comments

What permission in Windows is "Hide this file's existence"? I have never seen such a permission from the Explorer interface. It does disappear if I deny "read" permission. But that seems more than a little odd, since I'm allowing "execute", which for a folder, does control traversing & viewing of contents. So in principle I agree with your gist: if permissions are explicitly set to "hide this file", then that should be honored. I'm more concerned with "disallow read access but don't hide the existence", which is where GetAttributes() fails incorrectly.
@Mordachai: there is such a permission, but not on the file. It's the containing folder that may have it. In the ACL editor you can see it as "List folder contents". Side-note: "Read & execute" is a different permission on folders. Don't confuse this with the (comparably simplistic) Unix permissions :)
Please see my comment to Jerry, above = I am having a single file "disappear", not related to folder permissions.
@Mordachai: Please run fltmc (as admin) and append that output to your question. If that yields nothing unusual I reckon it's a special behavior of the network file system (server-side) or malware.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.