The following is an excerpt taken from http://www.openwall.com/lists/oss-security/2011/03/04/24:
Speaking of issues where a more or differently privileged process accesses files in a directory writable by another process, these are surprisingly difficult to "fully" deal with, and the majority of programs are "affected". Of the common Unix commands, only a handful are safe to use in untrusted directories (with possible impact of attacks being a mere DoS against the command itself) - such as "ln". Yes, I actually use "ln" like this: # su - user1 $ cp some/dir/file . # hopefully the ~/file name was not taken $ exit # ln ~user1/file . # ls -ld file # sanity check that we were not raced # chown user2: file # ln file ~user2/ # rm file # su - user2 $ mv file target/dir/ $ exit # su - user1 $ rm file when I need to copy a file from one untrusted user to another. Yes, this is complicated and it has limitations (same fs). Maybe we need a special tool for this task (I had some ideas on this - "give" and "take" commands). But that's the current situation. Almost all other commands and programs are unsafe on untrusted directories. In my opinion, that's the only correct assumption for a sysadmin to make, and any other assumption is naive. Unfortunately, most sysadmins don't fully realize this (in my experience), but that does not make those programs any safer, nor does it prompt us to assign CVE ids against almost all Unix programs.
Unfortunately, su is not perfect. An excerpt from http://www.openwall.com/lists/oss-security/2011/03/05/6:
The admin could "su" to the service pseudo-user, but that allows the compromised service to attack the admin's terminal, accessing the fd via /proc or ptrace of a process such as "less" running under the "su" session. Only "su" itself is immune from such attacks (since it has its "dumpable" flag cleared); its child processes are not. The attacker would be able to print control characters directly to the terminal fd, and to issue ioctl's on it, changing the terminal mode. This might have a security impact worse than DoS.