On 17 Jun 2000, Ton Hospel wrote:
[following broken symlinks]
> I think mknod (and possibly bind) should. They are more of a
> "creating a file" thing, while link and symlink are more namespace
> games.
Welcome to userland races. Please, grep the BUGTRAQ archives - you'll find
root exploits based on these.
> > b) I still want to hear what should happen upon
> > #!/bin/bash
> > exec 10>foo
> > rm foo
> > echo > /proc/$$/fd/10
> >
>
> What it should do seems pretty obvious. /proc/$$/fd/10 represents basically
> an open filedescriptor. That we nowadays show it as a symlink is an
> implementation accident. It should behave as if you write to filedescriptor
> 10. The inode is still there since the fd is open, so that nameless
> file should grow.
>
> If giving it these semantics is easy or not is an implementation detail.
> Maybe a hard or almost impossible detail, but a detail none the less.
It is trivial and current code will merrily do exactly that. Symlink is
_not_ broken in sense that follow_link() returns what we need. Is it
obvious that any algorithm along the lines "read the link contents and
repeat lookup" is doomed here? _No_ lookup will lead you to that file.
> > I really wonder whether we need this crapload of races at all.
> >
>
> Again, these are all implementation details. I dislike this
> "it does not fit the current model, so it is the wrong thing to do"
> mindset. Maybe it means that the current model of handling files
> is flawed, and should be extended.
>
> (from your description, repeatedly retrying (from scratch) getting the
> right locks until you win all races and have a known state seems the
> way to go. preferrebly so you only pay the multi attempt price in the
> case you now want to forbid outright).
Not so easy - we need a special case of follow_link() for that. Again, all
readlink()-based variants are doomed.
Wonderful... You know, I'll rather pass the decision on that to Linus -
it's my deep belief that following broken links in that situation is a bug
(the last remaining one from the large group of related bugs introduced in
4.2), but it is not serious enough to warrant a fork should Linus decide
to preserve it in his tree, so if he will decide that it should be
preserved - fine, I'll do that, but it will be butt-ugly.
Again, this is the only case when broken links may be followed - mknod()
and bind() must not do that unless you want to reintroduce exploitable
userland races.
-
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:14 EST