| Bug #14245 | grsec + NON glibc23 RPM packages executable stack problem | ||
|---|---|---|---|
| Submitted: | 23 Oct 2005 20:22 | Modified: | 6 Dec 2005 11:36 |
| Reporter: | D C | Email Updates: | |
| Status: | Won't fix | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 4.1.14 | OS: | Linux (Linux) |
| Assigned to: | CPU Architecture: | Any | |
[5 Nov 2005 9:19]
Valeriy Kravchuk
Thank you for a problem report. I'll try to figure out what flags are used for building glibc23 vs. NON-glibc23 with our build team and is it possible to add those flags you suggested. In the meantime, please, try to install and use latest 4.1.15 RPMs. Inform me about the results.
[5 Nov 2005 9:19]
Valeriy Kravchuk
Thank you for a problem report. I'll try to figure out what flags are used for building glibc23 vs. NON-glibc23 with our build team and is it possible to add those flags you suggested. In the meantime, please, try to install and use latest 4.1.15 RPMs. Inform me about the results.
[6 Dec 2005 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[6 Dec 2005 8:14]
D C
It does not matter which version I use. If I install non glibc23 version i get the error. I tried the follwing thing also: Download src.rpm package and compile it on RHEL 2 which is with glibc2.2. The buld process goes just fine and rpm-s are build but when I install them on system with glibc23 with grsec kernel it does the same thing. I seriously doubt that these flags will fix the problem. I guess in the older glibc is used some routine which loads the .so in data memory and then tries to make this memory executable with mprotect(). And since this function is restricted from grsec it fails.
[6 Dec 2005 11:36]
Lenz Grimmer
The affected RPMs are statically linked against a specially patched glibc-2.2.5 that uses a reduced thread stack size to allow more than 1024 concurrent threads. The linker on that build machine does not support the "noexecstack" link option and we don't plan to update it - please use the dynamically linked "glibc23" RPMs if you need to run MySQL in this specific environment. The static binaries are not suitable for this configuration.
[30 Jun 2006 13:00]
Leonardo Magalhaes
I had similar problem running official RPMs for 4.1.20 in a PaX enabled kernel. I had installed the packes: MySQL-server MySQL-client MySQL-devel MySQL-shared-compat all 4.1.20 in their NON-glibc23 versions. MySQL server and client were OK, no problem on that. But every single program that was linked to MySQL libraries were having problems, like: cannot enable executable stack as shared object requires: Permission denied I found it strange because i already had some machines running with PaX enabled kernels and didnt have problem like that. After some researching, i found that using MySQL-shared-compat-4.1.15 solved the problem. Seems that only versions newer than 4.1.15 of the shared-compat RPM were causing problems. So I stick with MySQL-server, client and devel 4.1.20 and shared-compat 4.1.15 for some days. And after some researching, i tried installing MySQL 4.1.20, including shared-compat, in their glibc23 versions. I'm running Fedora Core 4 which is glibc 23, so i could do that with no problems. After upgrading to the glibc 23 RPM versions, the problem didnt happen anymore. I'm using MySQL-server, devel, client and shared-compat 4.1.20.glibc23 versions and everything is fine. So, it's time for me to stop using those glibc22 versions and start using those glibc23 :) Hope this helps anyone that may found this on Google/search engines.
Description: Hi, I use Redhat baset distribution and use RPM-s from your download section. The kernel i custom build by me. Vanilla kernel from kernel.org with grsec+pax patch applied. Kernel version 2.6.11.12-grsec Here is the problem If I use packages: MySQL-client-4.1.14-0.i386.rpm MySQL-embedded-4.1.14-0.i386.rpm MySQL-shared-4.1.14-0.i386.rpm MySQL-devel-4.1.14-0.i386.rpm MySQL-server-4.1.14-0.i386.rpm On grsec enabled kernel with mprotect restriction turned on which means: mprotect restriction will prevent programs from - changing the executable status of memory pages that were not originally created as executable, - making read-only executable pages writable again, - creating executable pages from anonymous memory. When I try to start some program linked against libmysqlclient (for example php) I get the following error: error while loading shared libraries: libmysqlclient.so.14: cannot enable executable stack as shared object requires: Permission denied If I enable executable stack for the binary which loads libmysqlclient the problem disappears: execstack -s /usr/bin/php The problem disappears also if I use the glibc2.3 RPM-s: MySQL-client-4.1.14-0.glibc23.i386.rpm MySQL-embedded-4.1.14-0.glibc23.i386.rpm MySQL-shared-4.1.14-0.glibc23.i386.rpm MySQL-devel-4.1.14-0.glibc23.i386.rpm MySQL-server-4.1.14-0.glibc23.i386.rpm If I disable mprotect restriction from grsec the problem also disappears. If I compile mysql from source, the problem does not occur. The only problem is if I use NON glibc2.3 RPM-s from mysql.com I tested this on the following distributions: CentOS 4.1, 4.2 CentOS 3.5 Fedora Core 4 The behavior is absolutely the same on all of them. NON glibc RPM-s gives me the error mentioned above. Mysql server itself is running OK. How to repeat: Use RedHat based distro. CentOS 3.5, 4.1, 4.2 Fedora Core 4 Download kernel 2.6.11.12 from kernel.org Download kernel patch from www.grsecurity.net Compile the kernel with patch applied and with mprotect restriction enabled (from PAX option) Install non-glibc2.3 version of mysql RPMs from mysql.com Link any program against the client library libmysqlclient.so.14 (PHP in my case) execute the binary and the error appears. Suggested fix: I saw a post in internet which was saying that the programs should be compiled without executable stack. These are the options which should fix this kind of problem: LDFLAGS="$LDFLAGS -Wl,-z -Wl,noexecstack" I have not tested it but the guy was saying that this worked for him. Lots of other programs have exactly the same problem.