Grsecurity 2.0 (kernel 2.4.26) and Mysql

[adk]

At this moment I am running some test with grsecurity 2.0 (kernel 2.4.26)

However there are some problems with Mysql. Every time Mysql is started the following is logged:

grsec: signal 11 sent to /usr/libexec/mysqld[mysqld:6460] uid/euid:27/27 gid/egid:27/27, parent /usr/libexec/mysqld[mysqld:13424] uid/euid:27/27 gid/egid:27/27

On the same box Apache (+php) is running.

Does anyone know know how I can solve this problem ??

Thanks

Ad Koster

[Naucki]

i've mysql 4.0.20 / grsec 2.4.26-grsec2 / apache 2.0.50 / php 4.3.8 and no problems. securitylevel medium

on debian woody


signal 11 sound like an hardware/ram problem.
try out memtest.

[bsonderm]

Probably Mysqld accesses data outside a data segment. Signal 11 is a segmentation fault and is caused when a process accesses RAM outside it's reserved segments.
Grsecurity detects this and kills the mysqld process, so you can do a strace to see on which function call or signal Mysqld crashes.

e.g. strace /usr/local/mysql/bin/safe_mysqld will start the Mysqld processes.

When you have the line where Mysqld crashes you also have a clue where the bug in Mysql exists. After that ask support from Mysql to fix the problem or use chpax to turn of options for the Mysqld deamon. E.g. chpax -m /usr/local/mysql/bin/mysqld will turn of mprotect() and thus prevent probably Signal 11 Segmentation Faults.

Good Luck

[spender]

Again, grsecurity is not killing anything. It is simply logging the sigsegv that would have happened anyway.

-Brad

[adriano]

If you are running a version of RedHat that uses nptl threads, do the following and it'll fix your problem: export LD_ASSUME_KERNEL=2.4.0 (Thanks to spender for this one)

[adk]

If you are running a version of RedHat that uses nptl threads, do the following and it'll fix your problem: export LD_ASSUME_KERNEL=2.4.0 (Thanks to spender for this one)

Thanks.

This indeed solved my problem with mysql.