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.

It is fairly clear to me that requiring 'x' on shared libraries, etc,
doesn't fix a single security problem, it just changes what is needed to
be done to exploit some other hole.  [For that reason, and because someone
reasonably asked for the discussion to get off one of the lists that I
deleted tech-security from this message].

Once again, all this boils down to just what 'x' (S_IX??? really) means,
and that's not something that has ever been specified in this level of
detail that I know of.

kre