In article <Pine.GSO.4.10.10006130759490.24920-100000@weyl.math.psu.edu>,
Alexander Viro <viro@math.psu.edu> writes:
> 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.
I think mknod (and possibly bind) should. They are more of a
"creating a file" thing, while link and symlink are more namespace
games.
>
> 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.
> 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.
>
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).
-
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