Re: bug in symbolic links

Wolfgang Walter (walterw@wuerli.h3.stusta.mhn.de)
Fri, 14 Nov 1997 00:04:54 +0100


On Thu, Nov 13, 1997 at 02:23:48PM +0100, Peter Schmid wrote:
>
> There is a programm included in sendmail-8.8.7 which checks if symbolic
> links work.
> Linux-2.0.28 works.
> Linux-2.1.62 does not.
> Could someone please fix this problem.
>
> Peter
>
> /*
> ** This program tests your system to see if you have the lovely
> ** security-defeating semantics that an open with O_CREAT|O_EXCL
> ** set will successfully open a file named by a symbolic link that
> ** points to a non-existent file. Sadly, Posix is mute on what
> ** should happen in this situation.
> **
[snip]

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