seems to me this patch is no longer needed. i built glibc-2.15 on my hardened system with gcc-4.5.3 and localedef can still generate locales fine, and GNU_STACK looked OK: ET_DYN ---xe- 0755 LE RW- R-- RW- - - NOW /usr/bin/localedef if you have any idea why we need to keep this, speak up now.
(In reply to comment #0) > seems to me this patch is no longer needed. i built glibc-2.15 on my > hardened system with gcc-4.5.3 and localedef can still generate locales > fine, and GNU_STACK looked OK: > ET_DYN ---xe- 0755 LE RW- R-- RW- - - NOW /usr/bin/localedef > > if you have any idea why we need to keep this, speak up now. This was a history lesson in a big issue I never knew about. I get what the original issue was, I get how the patch addressed it, I see that this is not an issue now, but I don't know what's changed over the years. The only thing that makes me uneasy about removing it that I don't know what changed. But if you tested and you don't get the massive failures they wre hitting it 2003, I guess its over. I'm going to test with 4.6.3 and glibc-2.15. So I guess go ahead unless I start screaming.
i've queued the removal from glibc-2.16.0
(In reply to comment #2) > i've queued the removal from glibc-2.16.0 Since Aug 18, I've been running and working with a hardened amd64 virtual machines with glibc-2.16.0 minus patch 3000. No issues.
pushed out then. thanks!
hmm, i just saw this bug mentioned in today's glibc update... this patch has nothing to do with localedef (the nested function trampoline in it was fixed many years ago already), but everything to do with libraries that lack a GNU_STACK header which glibc's ld.so treats as requiring an executable stack (and the creation of which fails with an EACCESS under PaX/MPROTECT). now on gentoo you're not likely to see such libraries because the toolchain always emits a GNU_STACK header but there're binary apps out there created with an old enough toolchain where the libraries lack this header (initially all libraries lacked this header of course, that's why this patch was needed by everyone). to handle them you'll continue to need this patch or have to inject an appropriate GNU_STACK header into the affected libraries (iirc, execstack can do it).
(In reply to comment #5) since this isn't a problem for most packages now, i'm fine with pushing the problem out of the toolchain and onto the binary-only packages. if that means people who want to run such ELFs have to enable soft mode and modify the PaX settings on the ELFs (via xattrs), then so be it.
(In reply to comment #6) > since this isn't a problem for most packages now, i'm fine with pushing the > problem out of the toolchain and onto the binary-only packages. if that > means people who want to run such ELFs have to enable soft mode and modify > the PaX settings on the ELFs (via xattrs), then so be it. just for the record, that's the kind of cure that is worse than the disease ;). the problem with ld.so's handling of GNU_STACK is that it assumes that the legacy (GNU_STACK-less binaries) all need an executable stack, which is about never true (i've never seen one in the past decade). that's why PaX simply ignores it and uses EMUTRAMP explicitly where needed and that's what users should set properly in such cases as well. but all this is orthogonal to GNU_STACK as ld.so takes that (or lack thereof) into account instead, so that's why i said (security conscious) users should either keep patching ld.so or inject a GNU_STACK header into such libraries. it's the secure way, not disabling MPROTECT.
