On Tue, Oct 30, 2001 at 07:15:09AM -0800, Jason R Thorpe wrote:
> On Tue, Oct 30, 2001 at 10:06:57AM -0500, Thor Lancelot Simon wrote:
> 
>  > 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, we know, but unfortunately our world would break in other
> spectacular ways since we would be the only Unix system to enforce
> such a rule.

What ways, exactly?  The most obvious way I can think of is that we'd
need to whack libtool.

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.

It seems to me there are three choices: let programs lose when their shared
libraries are switched out from under them, let users make arbitrary readable
files read-only, or enforce the "x" bit the right way.

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.

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
    And now he couldn't remember when this passion had flown, leaving him so
  foolish and bewildered and astray: can any man?
						   William Styron