As far as I know, when I am creating a new file or directory in a directory that can be written by multiple users (and thus an adversary can have made a symlink there), the only way to protect myself from symlink race is creating a file with enough random name.

Well, some app might have checked if such file already exists, but I am not aware of any mechanism that is both atomic and able to detect symlinks.

So, when there are many non-random (or even reused) filenames in /tmp from various apps, it means all these apps are vulnerable to symlink race, doesn't it? (Well, it can't be simply decided if the vulnerability can be easily abused, but I don't care about practical exploitability for now.)

I hope I must be somewhere wrong.

  • Have you investigated mktemp?
    – MattBianco
    Commented Mar 5, 2015 at 10:08
  • 1
    @MattBianco Sure, it is just an implementation of "creating a file with enough random name". Unfortunately, it seems that there are many apps that don't use it.
    – v6ak
    Commented Mar 5, 2015 at 10:10
  • 1
    There's you answer then. It is as common as there are bad implementations of tempfile creation. One way of atomically creating a file is by (hard)linking to it with (ln without -s). Only one process will succeed in creating the link.
    – MattBianco
    Commented Mar 5, 2015 at 10:14
  • 7
    open(..., O_EXCL|O_CREAT) you could also use fd=open and fstat(fd to check if file is a link without having the race condition.
    – domen
    Commented Mar 5, 2015 at 11:29
  • 1
    @Infinite good catch. I wasn't clear enough. open with O_NOFOLLOW, then fstat to tell you if it's a symlink.
    – domen
    Commented Jan 20, 2017 at 20:16

1 Answer 1


So this should answer the question of "is symlink common?"

A search on the MITRE database shows there are 4 CVEs for a Linux Symlink Race condition vulnerability. For comparison, there are 2749 Linux CVEs known to MITRE.

Linux at the kernel level has protections against this. Kees Cook created a patch for Linux to prevent this problem:

The solution is to permit symlinks to only be followed when outside a sticky world-writable directory, or when the uid of the symlink and follower match, or when the directory owner matches the symlink's owner.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .