On Mon, Sep 12, 2005 at 06:18:22PM +0200, Roman Medina wrote: > Package: kernel-patch-grsecurity2 > Severity: critical > Justification: breaks unrelated software
> Grsec patch is incompatible with glibc post-v.2.3.2. I don't think that's actually true. From what I can tell, what happens is that glibc now enforces requests for an executable stack, and bails immediately at startup rather than risking a failure sometime later when one or more libraries has requested an executable stack. > http://lists.debian.org/debian-user/2005/08/msg00747.html This post describes a correct workaround, pending resolution of the bugs in libgcrypt, libcrypt, etc. > http://forums.grsecurity.net/viewtopic.php?t=1152 This thread doesn't seem to include posts from anyone who actually has a clue about the nature of the bug, or who has tried to file bug reports with Debian about it (other than the original poster). It does, however, include posts from at least one known troll. To the best of my knowledge, there are only a handful of significant libraries in Debian which have this bug; they should be fixed, but there is a known workaround for those applications which require an executable stack. This is not a glibc bug; there is no bug in *reporting* the kernel error when a library's request for an executable stack cannot be honored, and it is not glibc's job to decide which executable stack requests are legitimate and which are not. It is not a kernel-patch-grsecurity2 bug; grsec is working as advertised, and requires you to manually enable executable stack for any applications you wish to grant it to. Unless you can show that the workaround for some reason doesn't work for you, I think this bug should be closed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
