When writing secure code, it's almost always incorrect to "check, then do" anything. The reason is that between the checking whether you can do something and actually doing it, the state of the system could change such that doing it would have a different result.

For example, if you check whether a file exists before writing one, don't check whether you wrote the file successfully (or don't check in a detailed-enough fashion), and then later depend on the contents of the file you wrote, you could actually be reading a file written by an attacker.

So instead of checking file permissions, just do whatever it was you were going to do if the permissions check succeeded, and handle errors gracefully.

There are always feasible reasons for checking permissions, perhaps he's building a daemon for fixing permissions, which doesn't rely on his script to read or write to the files as a different process is going to do that.
–
Thomas Hunter IIMay 20 '11 at 14:44

Another example is a rewriteMap program which acts as a gate based on certain file permissions.
–
pukMar 21 '12 at 16:45