grsecurity forums

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

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.

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

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

-Brad

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)

adriano wrote: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.