Date:        Tue, 30 Oct 2001 10:06:57 -0500
    From:        Thor Lancelot Simon <tls@rek.tjls.com>
    Message-ID:  <20011030100657.B1764@rek.tjls.com>

  | I would like to point out that were my suggestion of only allowing
  | mappings of files *with execute permission* to be set PROT_EXEC
  | implemented, this problem (user can make file read-only by mapping
  | it PROT_EXEC) would not exist.

Yes it would.   Just to a lesser degree.   People may not be able to do
a DoS on /etc/passwd - but they would on any random file that happens to
have the 'x' bit turned on - like a shell script that you were trying to
debug and someone wants to make your life a bit more difficult.

But to basics again, is solving this problem (writing on shared libraries
that are in use) something that actually needs doing?   Its made very
difficult by the linker operating with the privs of the running program,
so anything it can do, any random program can do (which is different from
execve() where the kernel only allows suitably formatted binaries to be
run.  The kernel here doesn't get to check that the file is actually going
to be (or is able to be) executed - it is relying on the user to tell it.

When was the last time anyone here ever actually saw an ETXTBSY error?
(and I don't mean that you should go force it just to show that it can
happen - I mean in normal operation).

That error was introduced back when ld would simply creat(file,0777)
(or some mask like that) and then write onto it - meaning that if a
shared program was rebuilt anyone currently running it got screwed.
That annoyed people so much that it was made an error to try.   Of course,
that then annoyed the people building the programs and not being able to
link if anyone was running the old version (the ETXTBSY bit them) that they
changed ld so it creates a new file, and then moves it, rather than simply
writing on the target name.

Consequently these days, unless you deliberately set out to cause it,
people just don't get ETXTBSY any more - it is one of those errors that
just doesn't happen.

Has anyone here actually ever experienced a problem caused by having
a shared library overwritten while it is in use??

I thought not ... and it isn't as if there are security problems here,
all the relevant files are root owned, without write permission to the
public - so the only potential problem is if root deliberately decides
to go insane.   There are plenty of other vunerabilities in that case,
worrying that they're going to decide to break things by altering the
running libc.so file isn't high on my list of problems.

I think I'd just leave things as they are now, there isn't really a
problem that needs fixing, only the academic "why is this different"
question.

We could even delete ETXTBSY as the mouse suggested - it isn't as if
anyone would be rushing to change ld back to its old ways (nor do we tend
to build directly into the executable directories any more).   But given
it harms no-one, there's probably no reason to make that change either
(and it could make NetBSD fail to comply with some meaningless standards
requirement if we were to try - someone probably documented ETXTBSY).

kre