Re: Bug#321718: Upgrade caused many libs to complain about "executable stack"
On Sun, 2005-08-07 at 01:51 -0700, Steve Langasek wrote:
> > Google suggests this has something to do with "pax", which I've never
> > heard of and have certainly never installed or enabled.
>
> > -- System Information:
> > Debian Release: testing/unstable
> > APT prefers stable
> > APT policy: (500, 'stable')
> > Architecture: i386 (i686)
> > Shell: /bin/sh linked to /bin/bash
> > Kernel: Linux 2.4.18-bf2.4
> > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
[...]
> It should be straightforward for you to fix your system by installing a
> 2.4.27 kernel from sarge and rebooting the machine, which is the supported
> upgrade path in any case. This means the bug should not be considered
> critical; I've downgraded it accordingly.
>
> It is still important that the glibc package be fixed, so that it does not
> permit installation on an unsupported kernel. This has been done in the
> past for select architectures, but it seems we now have a reason to bump the
> requirement across all architectures, which should give the glibc team a
> nice clean start (and a nice clean preinst) for etch. :)
This bug appears with my 2.6.x grsecurity/PaX kernel too. I'm getting
similiar error with:
$ wget
wget: error while loading shared libraries: libcrypto.so.0.9.7: cannot
enable executable stack as shared object requires: Permission denied
It goes away after turning off mprotect() protection by chpax or
downgrading libc6 back to 2.3.2-ds1-22.
You might be interested in related threads at
- debian-user: http://lists.debian.org/debian-user/2005/08/msg00747.html
- grsecurity forums: http://forums.grsecurity.net/viewtopic.php?t=1152
Will it be fixed so that libc will work with grsecurity/PaX?
Reply to: