Re: [BUG] Kernel 2.4.0-test1-ac10 changes open of symlink behavior.

From: Alexander Viro (
Date: Tue Jun 13 2000 - 07:38:02 EST

On Tue, 13 Jun 2000, Andries Brouwer wrote:

> On Tue, Jun 13, 2000 at 02:57:19PM +1000, Daniel Pittman wrote:
> > > Compatibility, history, not breaking emacs..
> >
> > I followed the thread, but couldn't seem to see a conclusion
> > at the end of it.
> Not so impatient - there is no end yet to this thread.

OK, let me try to summarize:

a) open(name, O_CREAT, foo) is the *only* namespace-modifying operation
that follows broken symlinks. We all agree that rename(), rmdir() and
unlink() do not. We also agree that mkdir() does not. I claim that neither
mknod(), nor link(), nor symlink(), nor bind() on AF_UNIX sockets do (in
the last case several Unices follow link and that was the cause of
security holes). open() with any other value passed as the flags argument

b) I still want to hear what should happen upon
exec 10>foo
rm foo
echo > /proc/$$/fd/10

c) suppose we restore this insane semantics and somehow decide on
procfs-style links. Fine, but then we have a nice set of kernel races to
deal with. We follow the broken link. We need to lock the parent. During
that time target might
        1) become a file or directory. Fine.
        2) become a (possibly broken) symlink. Desired behaviour?
        3) become positive, be renamed away and there be removed. We are
_deep_ in it, since the name of dentry might silently change under us with
no evidence of such event. Moreover, if there is an evidence (parent had
been changed) we either need to repeat the lookup or drop the lock on old
parent and acquire the lock on new one. Lather, rinse, repeat.
        4) be renamed over. Repeat lookup? It is unhashed now...

If we repeat lookups we have to deal with possibility that symlink had
been changed/removed - we have slept. There also is a slew of other funny
races to deal with and the whole thing makes JCL look elegant in

Variants with follow_link() giving us parent + name of last component are
also interesting due to procfs-style links. Same (even in worse form) goes
for textual substitution of readlink() result.

I really wonder whether we need this crapload of races at all.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:11 EST