Symlink giving "Permission denied"... to root

Question

I wrote a simple script to automate creating a symbolic link.

#!/pseudo
today = "/tmp/" + date("Y-m-d")
exec("ln -sf " + today + " /tmp/today")

Simple enough; get today's date and make a symlink. Ideally run after midnight with -f so it just updates it in-place.

This works just fine! ...for my user.

xkeeper /tmp$ ls -ltr
drwxrwxrwx  xkeeper   xkeeper   2014-10-21
lrwxrwxrwx  xkeeper   xkeeper   today -> /tmp/2014-10-21/

xkeeper /tmp$ cd today
xkeeper /tmp/today$ cd ..

Notice that it works fine, all the permissions are world-readable, everything looks good.

But if someone else wants to use this link (we'll say, root, but any other user has this problem), something very strange happens:

root /tmp# cd today
bash: cd: today: Permission denied

I am at a complete loss as to why this is. I've also tried creating the links with ln -s -n -f (not that "--no-dereferencing" is very well-explained), but the same issue appears.

Cindycine

Note that it works perfectly fine if I create the link itself with root (all other users have access to it), but that doesn't really explain why it doesn't work if created by other users. – Cindycine

What means #!/pseudo ? – Scolecite

Okay, very strange. I tried creating a link in the same way in a temporary folder somewhere in /var/www/, and it worked as expected, without permission errors. What in the world. – Cindycine

@wenzul ...wha? Is there a reference for this? This is the first time I've ever heard such a thing and Googling turns up nothing. It also goes against the traditional role of root both in 40 years of Unix and in computing in general... – Hobbs

@Hobbs Ok I meant this difference behaivor for /tmp amongst others, but may used the wrong words... – Citation

Answer 1

Since /tmp usually has the sticky bit set, the access to /tmp/today is denied because of protected_symlinks. You can disable this protection by setting

sysctl -w fs.protected_symlinks=0

protected_symlinks:

A long-standing class of security issues is the symlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given symlink (i.e. a root process follows a symlink belonging to another user). For a likely incomplete list of hundreds of examples across the years, please see: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp

When set to "0", symlink following behavior is unrestricted.

When set to "1" symlinks are permitted to be followed only 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.

This protection is based on the restrictions in Openwall and grsecurity.

For further details check this.

Citation

That makes sense, and explains why it worked in other directories... Also explains why creating a link as root works (because root also owns /tmp). – Cindycine

Excellent answer, this saved me a lot of grief. Thanks! – Reese