On Fri, Oct 19, 2001 at 06:07:31PM +0700, Robert Elz wrote:
>     Date:        Thu, 18 Oct 2001 19:38:36 -0400
>     From:        Thor Lancelot Simon <tls@rek.tjls.com>
>     Message-ID:  <20011018193836.B8908@rek.tjls.com>
> 
>   | So what?  I suggest that the treatment should be exactly the same as for
>   | executable files: the x bit should not be honored if noexec is set, and
>   | if the x bit is not present or not honored, the code should not be executed.
> 
> Like many arguments that seem to happen here (and elsewhere) part of this
> comes down to what the 'x' bit actually means, or should mean.
> 
> Leaving aside directories, where it is completely different, and irrelevant
> here (and probably sockets, fifos and all kinds of other weird things), 'x'
> can mean either "contains code that can be executed" or "this is a file that
> it is reasonable to exec(2) (and if that fails, to emulate somehow)"
> 
> Until recently (in comparative terms) it made no difference, as the only
> code that was ever executed got to be executed because of exec() (in any
> normal environment anyway).
> 
> Now however, code gets to be executed from shared libraries, dll's, and
> possibly other ways, aside from exec().   It isn't at all clear that the
> 'x' bit is the right way to control that.
> 
> Personally, I think I prefer to keep the 'x' bit clear on anything that
> isn't meant to be run as a command of some kind (and directories...).
> That lessens the confusion that happens when someone sees the 'x' set,
> assumes they must be able to run it, the magic number test fails, and so
> something decides it must be some kind of shell script and asks a shell
> to run the thing.

I'm persuaded by this argument.  I now agree that simply having the
"noexec" mount flag checked before mapping with PROT_EXEC probably does
what I want: prevent shared libraries on "noexec" volumes from being used.