There is a remark in fs/namei.c that the semantics has changed, so it seems
to be done intentionally. Though, I think it is a rather bad change, too,
especially as some programs as sendmail behave different for 2.1 and 2.0
kernels. Almost all programs using /tmp may become a potential security hole
when switching from 2.0 to 2.1.
>From fs/namei.c (2.1.63):
/* [Feb-1997 T. Schoebel-Theuer]
* Fundamental changes in the pathname lookup mechanisms (namei)
* were necessary because of omirr. The reason is that omirr needs
* to know the _real_ pathname, not the user-supplied one, in case
* of symlinks (and also when transname replacements occur).
*
* The new code replaces the old recursive symlink resolution with
* an iterative one (in case of non-nested symlink chains). It does
* this by looking up the symlink name from the particular filesystem,
* and then follows this name as if it were a user-supplied one. This
* is done solely in the VFS level, such that <fs>_follow_link() is not
* used any more and could be removed in future. As a side effect,
* dir_namei(), _namei() and follow_link() are now replaced with a single
* function lookup_dentry() that can handle all the special cases of the former
* code.
*
* With the new dcache, the pathname is stored at each inode, at least as
* long as the refcount of the inode is positive. As a side effect, the
* size of the dcache depends on the inode cache and thus is dynamic.
*/
Wolfgang