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
doesn't.
b) I still want to hear what should happen upon
#!/bin/bash
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
comparison.
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:11 EST