drwxrwxrwx,符号链接将“权限被拒绝”授予根目录

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.

解决方案

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

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.