Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
Have you investigated mktemp? – MattBianco Mar 5 '15 at 10:08
@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 Mar 5 '15 at 10:10
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 Mar 5 '15 at 10:14
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 Mar 5 '15 at 11:29
@domen Thanks, this looks to be more likely… – v6ak Mar 8 '15 at 14:01
up vote 2 down vote accepted

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.