[MDEV-11676] Starting service with mysqld_safe_helper fails in SELINUX "enforcing" mode Created: 2016-12-28  Updated: 2017-02-16  Resolved: 2017-01-04

Status: Closed
Project: MariaDB Server
Component/s: Scripts & Clients
Affects Version/s: 5.5.54
Fix Version/s: 5.5.55

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Sergei Golubchik
Resolution: Fixed Votes: 1
Labels: None
Environment:

RHEL6 / CentOS6 - tested with centos/6 VM base image for Vagrant which is CentOS 6.8 at this point

Issue Links:
Relates
relates to MDEV-12074 selinux build failure on Fedora 24 Closed

 Description   

service mysql start bails out with weird error message from the new mysqld_safe_helper binary when having log-error option set in either [mysqld] or [mysqld_safe] section of my.cnf. Whether log-error is used with an explicit file name argument or not doesn't matter. Also when not having log-error in the config file at all mysqld_safe_helper is still throwing an error, but in this case the service startup script reports SUCCESS instead of ERROR

The error message is 

# service mysql start
 
Starting MySQL.161228 12:32:33 mysqld_safe Logging to '/var/lib/mysql/localhost.localdomain.err'.
 
161228 12:32:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
 
/usr/bin/mysqld_safe_helper: Can't create/write to file '' (Errcode: -597589344)

(Jira does not show this, but the actual file name shown in the error message is the unicode placeholder character for code point U+0001, and not just an empty string)

The actual error code varies and is usually a large positive or negative value, but not a valid error code.

When looking at strace output the parameters passed to mysqld_safe_helper look fine:

execve("/usr/bin/mysqld_safe_helper", ["/usr/bin/mysqld_safe_helper", "mysql", "log", "/var/lib/mysql/localhost.localdomain.err"], ["TERM=xterm", "PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin", "PWD=/usr", "SHLVL=2", "MYSQL_HOME=/usr", "_=/usr/bin/mysqld_safe_helper"]) = 0

Also when running mysqld_safe_helper with the same arguments manually it works as expected without throwing an error at all:

/usr/bin/mysqld_safe_helper mysql log /var/lib/mysql/localhost.localdomain.err

Also when passing in an invalid file name a correct error message is displayed (^A here was entered using CTRL-V CTRL-A, so it is really 0x01

/usr/bin/mysqld_safe_helper mysql log ^A
 
/usr/bin/mysqld_safe_helper: Can't create/write to file '' (Errcode: 13)

(again the file name in the actual error message is the U+0001 unicode placeholder, and not just an empty string)

 Comments   
Comment by Hartmut Holzgraefe [ 2016-12-28 ]

Service startup now also fails after removing log-error from the configuration file again, so this is not a reliable workaround either ...

Comment by Hartmut Holzgraefe [ 2016-12-28 ]

How to reproduce:

  • set up VM 

    vagrant init centos/6
    		 
    vagrant up
    		 
    vagrant ssh

  • in VM shell 

    sudo bash
    		 
     
    		 
    cat > /etc/yum.repos.d/mariadb.repo <<EOF
    		 
    [mariadb]
    		 
    name = MariaDB
    		 
    baseurl = http://yum.mariadb.org/5.5/centos6-amd64
    		 
    gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
    		 
    gpgcheck=1
    		 
    EOF
    		 
     
    		 
    yum install MariaDB-server
    		 
     
    		 
    service mysql start

Comment by Hartmut Holzgraefe [ 2016-12-30 ]

Turns out the actual problem is SELINUX=enforcing mode preventing changing the effective user ID for this new binary unknown to it.

from failing invocations strace:

4888  execve("/usr/bin/mysqld_safe_helper", ["/usr/bin/mysqld_safe_helper", "mysql", "log", "/var/lib/mysql/localhost.localdo"...], [/* 6 vars */] <unfinished ...>
 
[...]
 
4888  setgroups(1, [499])               = -1 EPERM (Operation not permitted)
 
4888  setgid(499)                       = -1 EPERM (Operation not permitted)
 
4888  write(2, "/usr/bin/mysqld_safe_helper", 27) = 27
 
4888  write(2, ": ", 2)                 = 2
 
4888  write(2, "Can't create/write to file '\1' ("..., 51) = 51
 
4888  write(2, "\n", 1)                 = 1
 
4888  clock_gettime(CLOCK_REALTIME, {1483100529, 629773869}) = 0
 
4888  exit_group(1)

So the failure is understandable now ... not the source of the misleading error message though as it seems to stem from my_set_user() and not related to file system access at all ...

Comment by Sergei Golubchik [ 2017-01-05 ]

See also https://lists.launchpad.net/maria-discuss/msg04237.html

Generated at Thu Feb 08 07:51:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.