On Tue, Jun 13, 2000 at 08:38:02AM -0400, Alexander Viro wrote:
> 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.
[Checking draft standard]
rename, rmdir, unlink, mkdir, symlink: agree
mknod: agree - but the draft fails to say anything - I filed an erratum
link: agree, but the draft could be more explicit
bind: maybe the draft does not say anything here.
So, yes, I agree.
> b) I still want to hear what should happen upon
> #!/bin/bash
> exec 10>foo
> rm foo
> echo > /proc/$$/fd/10
I do not consider that very important.
> 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.
Maybe not. Let us see. Foo is a symlink and contains bar/baz.
Someone does open("Foo", O_CREAT, mode).
The kernel inspects the file Foo, finds that it is a symlink,
reads its contents, and decides that the open is equivalent
to open("bar/baz", O_CREAT, mode).
So far the fact that the symlink was dangling did not play a role.
But in open("bar/baz", O_CREAT, mode) this dangling symlink is gone,
we have an ordinary path name, and know already what to do.
You have spent more time thinking about these matters, maybe
I overlook something, but at first sight I cannot see any problem.
Andries
-
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 : Thu Jun 15 2000 - 21:00:29 EST