> As you say, there's still a race. It's better to leave a gaping
> hole which obviously needs fixing than a subtle one, so Linus
> wouldn't accept it.
>
> How about:
>
> lock_vfs()
> stat()
> open()
> unlock_vfs()
>
> As I said, it's only useful in the core dump case, but that's the
> original context of this discussion. We can worry about safe temp
> file creation later.
Hmm... I'm not sure how the lock_vfs semantics would work and no
interfere with the stat and open calls.
Assuming that isn't a problem, this isn't a bad solution but it would
suck rocks for time critical stuff (rt-linux?) which might be writing
data out to disk, then some other process goes and dumps core on an
old ESDI same-day-service disk with abysmal seeks times... (making
the stat take a _long_ time, the open would be a (d)cache hit).
I'm thinking this is much harder than I envisaged, and we should
declare core dumps and root `a bad thing' until we can get O_NOFOLLOW
semantics in the vfs.
Perhaps a sysclt /proc/sys/kernel/allow_root_coredump ?
-cw
-
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/