On Tue, 30 Oct 2001, Thor Lancelot Simon wrote:

> On Tue, Oct 30, 2001 at 07:15:09AM -0800, Jason R Thorpe wrote:
>
> I don't really see what else you can do here and get correct behaviour.
> If you really want to be sure executable code doesn't change while it's
> being executed, you *have* to make it read-only.  However, you don't
> want users to be able to run a denial-of-service against your system
> by making any readable file read-only by mapping it PROT_EXEC.  This
> sure seems to me like a problem that proceeds *directly* from the fact
> that we don't enforce the semantics of the "x" permission in the filesystem
> correctly.

We actually do, as best I can tell, enforce the "x" permission correctly.
We just enforce a different definition than the one you want us to
enforce. "x" meens you can exec() the file. Machine instructions are an
orthogonal question to exec()ability. Shared libs have machine code in
them, but can't be exec()ed, and shell scripts have no machine code, and
yet are exec()able.

> How about this, as a compromise:  only make the vnode read-only when
> mapping PROT_EXEC *if* it's executable.  That way at least clueful
> creators of shared libraries (e.g. us) can prevent them from being written
> while in use, while users can't make it impossible to write to any *other*
> files they can read -- but shared libs not marked executable will still
> work, though not have write protection while in use.

This idea matches one I had.

But I think we should take a step back. The goal of this thread was mainly
to stop libc from getting paged out (or more specifically so that libs get
counted as program pages, not random data). We aren't the first OS to face
this, and the others (ALL the others AFAICT) seem to have not needed to
mark their shared libraries as executable. So how did they do it, and why
shouldn't we do things that way?

Take care,

Bill