It is enforced by the kernel, but it sounds like in your case NFS was
involved.
Interestingly, shared libraries *are* protected against writing while in
use on SCO_SV 3.2v5.0.6 (below). Maybe it has the potential race
condition, though?
# ls -lR
total 4
drwxr-xr-x 2 jake group 512 Jun 16 22:44 bin
drwxr-xr-x 3 jake group 512 Jun 16 22:43 usr
./bin:
total 120
-rwxr-xr-x 1 jake group 59892 Jun 16 22:44 sh
./usr:
total 2
drwxr-xr-x 2 jake group 512 Jun 16 22:44 lib
./usr/lib:
total 734
-rwxrwxrwx 1 jake group 372160 Jun 16 22:44 libc.so.1
# chroot . /bin/sh
# > bin/sh
bin/sh: cannot create
# > usr/lib/libc.so.1
usr/lib/libc.so.1: cannot create
# exit
# > usr/lib/libc.so.1
# uname -a
SCO_SV xxxxx 3.2 5.0.6 i386
On Wed, 16 Jun 2010, 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".
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
