On Wed, 2010-06-16 at 18:58 -0700, Rob Sherwood wrote:
> I don't have a chance to test this now, but my guess is that it's not
> the kernel that's stopping this but the shell with some kinda of
> advisory locking. Unless this is a new features, in the past, you can
> definitely overwrite running binaries, as I've discovery much to my
> chagrin:
>
> 1) build new xterm
> 2) copy new xterm over old xterm
> 3) wait for screaming mail to stop because you crashed every xterm in
> the department
>
> The thing to test is whether you can `cp` over the file instead of
> ">filename".
cp also gives ETXTBSY. strace shows that the error is definitely coming
from the kernel:
$ strace cp /dev/null bash 2>&1 | grep ETXTBSY
open("bash", O_WRONLY|O_TRUNC) = -1 ETXTBSY (Text file busy)
> Besides, it's unclear to me that this is really a DoS because you can
> still unlink(2) or rename(2) the file.
Yes, I was a little imprecise. People typically install binaries with
tools that are smart enough to do that. But it would be ridiculous if
every application that writes to a world-readable log file had to defend
against users mapping the file with MAP_DENYWRITE. That's why I'm
proposing that MAP_DENYWRITE should be allowed only for files with
execute permission. (I'm not sure why gcc creates shared libraries as
executable by default, since almost all of them crash when executed
directly, but it would come in handy here.)
--
Matt
