First, don't bother trying to check file permissions. The only real way to check file permissions is when you try the actual operation. So check for failure and report a good error message.

You might see advice to use access() to check permissions but that is a bit of a misleading API. It was never meant for checking generic file permissions. It was meant only for use by set-UID programs to make a rough guess about whether the file would be accessible by the user once set-UID was taken away. And it only gives a rough guess, ignoring lots of potential reasons for an access to fail or succeed.

Second, the way you talk about this checking makes it sound like you are just going to generate a bunch of race conditions. For example, checking whether a file exists, say with -e, before attempting to overwrite causes a race condition. Instead, open the file in a way that will fail if the file exists then you can check if the file existing is what caused the open to fail and deal with it at that point.

But if, for example, your desired behavior to avoid overwriting a file is to rename the current file before opening the new one, then you still need to open the new file in a way that will fail if the file already exists or you get a race condition again.

The symlink trick only works when a privileged program (such as a set-UID program) keeps its privileges while working with files in a directory that it doesn't need its privileges for (such as /tmp). Because if you can use a symlink to redirect non-/tmp files, then you have privilege to just directly move the file and don't need a symlink trick.

A much better solution than checking for symlinks is to have your set-UID program remove its privileges whenever it deals with places where it doesn't need them.

I don't think checking for tricky things is usually a good idea. If your program isn't set-UID (or privileged in some other way), then these tricks really don't pose a security hole and may actually be used legitimately to work-around some temporary system problem.

But even if there are no security issues to worry about, it is a good idea to avoid race conditions.

        - tye (but my friends call me "Tye")