>> I've got a feeling that the problem we really want to fix is shared
>> libs on noexec filesystems, not shared libs minus the execute bit
>> in the file system...
>
>Yeah, let's do a special-purpose hack instead of actually enforcing the
>consistent rule that executable code has to come from an executable file.

that's not *really* a special-purpose hack, it just makes sense.  we
could always do both.

>Gack.

the only other idea i have is building everything statically and
deleting ld.so so that you *can't* use shared libraries.  of course,
one could still read in some foo, mprotect() it, and go off again,
althought presumably the applications that you would be trying to
trick wouldn't be doing this *anyway*.

i think the thing we're trying to defeat here is people who would
LD_PRELOAD an object that contained an ftp client so that when
/usr/bin/mesg (for example) called getopt(3), it wouldn't jump to the
"main()" of your ftp client object stuff.

let's not make mountains out of molehills.  disallowing the mmap()ing
of object code to be executed from filesystems that are mounted noexec
definitely takes care of the latter.  the former is too much a
mountain.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."