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". Besides, it's unclear to me that this is really a DoS because you can still unlink(2) or rename(2) the file. - Rob . On Wed, Jun 16, 2010 at 5:02 PM, Richard Matthew McCutchen <rmccu...@umd.edu> wrote: > I noticed the following funny behavior on Linux: > > $ cp /bin/bash /lib64/libc.so.6 . > $ LD_LIBRARY_PATH=. ./bash > # In the subshell... > $ >bash > bash: bash: Text file busy > $ >libc.so.6 > Bus error (core dumped) > > So evidently the kernel prevents executables from being overwritten > while in use, but there is no analogous feature for shared libraries. > It seems to me that there should be. > > I notice that glibc passes MAP_DENYWRITE when mapping the shared > portions of shared libraries. The mmap(2) man page says: > > MAP_DENYWRITE > This flag is ignored. (Long ago, it signaled > that attempts to write to the underlying file > should fail with ETXTBUSY. But this was a > source of denial-of-service attacks.) > > Hmm... so executing a file is also a denial-of-service attack. Maybe a > reasonable compromise would be to honor MAP_DENYWRITE for files on which > the process has execute permission. Alternatively, the kernel could be > enhanced so that writes to a file never affect pre-existing private > mappings (the behavior is currently undefined), but I imagine that would > be a lot more work. > > Thoughts? What would be the right place to raise this issue: LKML? > > -- > Matt > >
