Date: Mon, 03 Feb 2014 10:36:25 -0500
From: David Levine <levinedl(_at_)acm(_dot_)org>
Message-ID: <19453-1391441785(_dot_)792050(_at_)OXRU(_dot_)R4ek(_dot_)QGuP>
| I wonder why someone even bothered to write that sentence if the
| ordered interpretation is correct.
Whoever wrote it was just trying to be correct, but not imagining that
anybody could read it as allowing the interpretation you have suggested,
so didn't bother excluding that. I cannot even imagine how one would
make an implementation that behaved that way, if that was an explicit aim,
rather than just some unfortunate side effect. To rename("a", "b") any old b
must be unlinked. Before that happens is just the "before rename" case.
After that unlink, figuring out ow to make b temporarily reappear as the old
file (while eventually completing the rename, so a has gone - but its contents
must be in b after the rename has fully completed) would take some
ingenuity. There are times when simply believing that the simple way
applies is the right thing to do.
| But as it was written, it allowed the implementation to disclaim ordering.
Even if that were true, what would it matter? We know there's a race if
some other program is attempting to access b just around the time of the
rename. Even if some weird come & go ordering applied during the rename,
anyone that sees the old b contets can simply be regarded as having won the
race, and anyone who sees the new b (old a) contents lost the race, and
even if there were two of those processes, and somehow one lost, and
immediately after, the other won, all this happens within the period of the
rename sys call operation, so it is all very quick - there's no way the two
processes could tell which order they executed.
| Even without that, there is an opportuntity for a particular DoS
| attack with mkstemp + rename (in pseudocode):
Yes, of course, I mentioned that (without the detail) in the previous
message. mkstemps() sounds as if it avoids that, but link()/unlink()
cannot (and nor can mkstemp();link() without the unlink() as in your
pseudocode the file created by mkstemp is being used to fuel the attack,
rather than guard against it.)
| Sure, we can't prevent all DoS attacks on shared resources. But
| there's no need for us to allow a particular one on the platforms
| that have a C library call that does exactly what we want.
No, and I wasn't arguing against using mkstemps() where it is available,
just against using link() in preference to rename() - that one makes no
sense.
| "mkstemps() first appeared in OpenBSD 2.4".
Oh, OK, given all those systems, I guess it is about time for it to
migrate to NetBSD as well (it isn't there yet.)
kre
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers