Bill,
PSARC approved a case a while back that changed "expected or
normal or correct" operation for "faster" operation. Because
implementing that change broke "expected" behavior, find and other
utilities started reporting possible false positives saying that a
directory changed between a *stat*() operation and a following
opendir(). A bunch of changes have been made trying to stop reporting
false positives without making the security hole worse.
This case tries to allow applications to determine that they
have just stat()ed a file that may generate a false positive. It does
do that. But there is still no way to determine whether the directory
opened by the opendir() was the requested directory or a spoofed
directory planted into the file hierarchy between the original *stat*()
call and the opendir() call. Since it leaves the security hole
unplugged, I don't see that it buys us anything while it any
application trying to use this feature unportable.
- Don
>Date: Wed, 03 Oct 2007 18:51:27 -0400
>From: Bill Sommerfeld <sommerfeld at sun.com>
>
>On Wed, 2007-10-03 at 17:12 -0500, Tom Haynes wrote:
>> Is this an artifact of the existing code inside walk() or from the new
>> feature?
>
>Both.
>
>> I.e., I can't find a crisp definition of what threats the original
>> code dealt with - I've heard that it handles symlinks and when a
>> subtree is moved.
>
>It's premature to change the existing code until you can explain both
>the problem it's trying to solve and the way it's getting it wrong.
>
>We can do better than rumor and superstition.
>
>I suggest looking at the change history of the source file and reading
>all the CR's for past changes.
>
> - Bill
