Failing CentOS5-32 builds in Jenkins

Bug #1153334 reported by Alexey Kopytov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraBackup moved to https://jira.percona.com/projects/PXB
Fix Released
High
Alexey Kopytov
2.0
Fix Released
High
Alexey Kopytov
2.1
Fix Released
High
Alexey Kopytov

Bug Description

All XB tests in the 'innodb51' configuration fail on centos5-32 Jenkins slaves due to SELinux when trying to start the server from a non-standard location. innodb51 is the only configuration where the server needs to load a plugin. That fails as follows:

130310 22:37:45 [ERROR] Can't open shared library '/home/user/src/2.0/test/server/lib/plugin/ha_innodb_plugin.so' (errno: 22 cannot restore segment prot after reloc: Permission denied)
130310 22:37:45 [ERROR] Couldn't load plugin named 'innodb' with soname 'ha_innodb_plugin.so'.

Corresponding messages from /var/log/audit/audit.log:

type=AVC msg=audit(1362938338.731:89): avc: denied { execmod } for pid=27233 comm="mysqld" path="/home/user/src/2.0/test/server/lib/plugin/ha_innodb_plugin.so.0.0.0" dev=dm-0 ino=1246369 scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1362938338.731:89): arch=40000003 syscall=125 success=no exit=-13 a0=4a3000 a1=13e000 a2=5 a3=bfe27610 items=0 ppid=27167 pid=27233 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=3 comm="mysqld" exe="/home/user/src/2.0/test/server/bin/mysqld" subj=user_u:system_r:unconfined_t:s0 key=(null)

"setenforce=0" on those slaves would fix the issue, but that appears to be too difficult. This report is to implement a workaround in the XB test suite.

Related branches

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

If this bug can reappear in non-testing environment due to other
reasons, I can add this as an exception to selinux rule.

However, according to http://danwalsh.livejournal.com/6117.html?thread=23525
"
 Basically a DSO is loaded, at some point the application determines the code needs text relocation and uses the mprotect call to set the memory region read/write. After the text relocation, the code is marked back to read/exec which triggers the access check. Usually the DSO does not need to be text relocatable, but a programming mistake has happened.
"

So, bug fix helps here, also, I checked for others on CentOS64-6
with readelf -d PROGRAMS | fgrep TEXTREL -- couldn't find any.

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-355

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.