On 17 Jun 2000, Ton Hospel wrote:
> In article <Pine.GSO.4.10.10006170117280.676-100000@weyl.math.psu.edu>,
> Alexander Viro <viro@math.psu.edu> writes:
> > 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.
> >
> I could just as well argue that the PROGRAM is wrong in making the wrong
> assumptions about behaviour of symlinks. Unless there is NOW a standard
> that says syumplinks to mknod/bind should not be followed (I know of
> none like that currently).
>
> Just as programs that create /tmp files and follow symlinks to e.g.
> /etc/passwd should not lead to "don't follow symlinks in /tmp", but
> "the program is buggy".
Yes, sir. And how, pray tell me, could one safely create named pipes in
aforementioned /tmp if mknod(2) would follow links? O_EXCL does not apply
here - mknod does not have a 'flags' argument.
Could you please realize that historical behaviour can be <gasp> wrong?
Case in point: Linux used to follow links on coredump. Program that dumps
core definitely has a bug, no arguments here. However, programs _are_
buggy. Too fscking bad, thing had too large abuse potential and it had
been taken away, standards or not. Complaints to Dave Null, please.
Historically, one could link(2) to directories. Historically, one could
create directories with ".." pointing to any place. Historically, mkdir(1)
had to be suid-root, BTW. Historically, one could read(2) a directory and
expect an array of 16-byte entries containing a 14-byte name + 2-byte
inode number. Too bad, it did not make sense on FFS and it had been
<drumrolls> taken out and shot. Later one might expect readdir(2) to
return no duplicates. Too bad, when union-mounts went into 4.4 this
assumption became a problem. There it went. Userland that really cared had
been fixed.
I have a lot of respect to Kirk, but semantics he had chosen for symlinks
turned out to be a mistake. Some parts had been fixed in 4.3, some - in
4.4, some - only in 4.4 derivatives. Thing in question is the only
remaining part of the bug. And IMO we should preserve it only if there is
a lot of hard-to-fix userland code depending on it.
-
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:15 EST