Subject: Re: PROT_EXEC mappings of vnodes -> VTEXT
To: None <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 10/30/2001 10:28:24
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
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 email@example.com
And now he couldn't remember when this passion had flown, leaving him so
foolish and bewildered and astray: can any man?