Bug 153927
Summary: | mysqld fails to start, due to missing rights to access /var/lib/mysql | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Boris Glawe <public> |
Component: | mysql | Assignee: | Tom Lane <tgl> |
Status: | CLOSED ERRATA | QA Contact: | David Lawrence <dkl> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | dwalsh, hhorak, sundaram |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 1.18.1-2.12 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-05 07:24:06 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Boris Glawe
2005-04-05 21:24:59 UTC
It sounds like a selinux issue, indeed ... but you have not provided either mysql or selinux package version numbers so there's not much hope of giving specific information. I'd suggest updating both of those packages to latest available versions and doing "restorecon -R /var/ lib/mysql" to be sure that everything in that directory is properly labeled. I tried the restorecon command - but it didn't help! Both server and client are in version mysql-3.23.58-16.FC3.1 The selinux-policy is in version selinux-policy-targeted-1.17.30-2.93 => the system is up2date. I am updating my system as soon as the updates are released. I've had this problem for a long time. It's not a problem that came with the last update. Actually, looking closer at the /var/log/messages entry, it seems to be complaining about a directory named "lib", which suggests that the bogus selinux setting may actually be on /var/lib. Or maybe somewhere else ... the inode number is the only definitive indication there. Anyway, find the directory with inode 240482 and try a restorecon on that. I did a restorecon -R /var Unfortunately with no success. Where else can be something called "lib" which mysqld wants to access? According to /var/log/mysqld.log access to /var/lib/mysql was refused, which caused it to terminate. In the hope that this is the instance which controls the access, I post you both my /etc/selinux/targeted/src/policy/file_contexts/program/mysqld.fc and my /etc/selinux/targeted/src/policy/domains/program/mysqld.te ################################################## # mysql database server /usr/sbin/mysqld(-max)? -- system_u:object_r:mysqld_exec_t /usr/libexec/mysqld -- system_u:object_r:mysqld_exec_t /var/run/mysqld(/.*)? system_u:object_r:mysqld_var_run_t /var/log/mysql.* -- system_u:object_r:mysqld_log_t /var/lib/mysql(/.*)? system_u:object_r:mysqld_db_t /var/lib/mysql/mysql\.sock -s system_u:object_r:mysqld_var_run_t /etc/my\.cnf -- system_u:object_r:mysqld_etc_t /etc/mysql(/.*)? system_u:object_r:mysqld_etc_t ifdef(`distro_debian', ` /etc/mysql/debian-start -- system_u:object_r:bin_t ') ################################################## And here is my /etc/selinux/targeted/src/policy/domains/program/mysqld.te ################################################## #DESC Mysqld - Database server # # Author: Russell Coker <russell.au> # X-Debian-Packages: mysql-server # ################################# # # Rules for the mysqld_t domain. # # mysqld_exec_t is the type of the mysqld executable. # daemon_domain(mysqld) type mysqld_port_t, port_type; allow mysqld_t mysqld_port_t:tcp_socket name_bind; allow mysqld_t mysqld_var_run_t:sock_file create_file_perms; etcdir_domain(mysqld) typealias mysqld_etc_t alias etc_mysqld_t; type mysqld_db_t, file_type, sysadmfile; log_domain(mysqld) # for temporary tables tmp_domain(mysqld) allow mysqld_t usr_t:file { getattr read }; allow mysqld_t self:fifo_file { read write }; allow mysqld_t self:unix_stream_socket create_stream_socket_perms; allow initrc_t mysqld_t:unix_stream_socket connectto; allow initrc_t mysqld_var_run_t:sock_file write; allow initrc_t mysqld_log_t:file { write append setattr ioctl }; allow mysqld_t self:capability { dac_override setgid setuid net_bind_service }; allow mysqld_t self:process getsched; allow mysqld_t proc_t:file { getattr read }; # Allow access to the mysqld databases create_dir_file(mysqld_t, mysqld_db_t) allow mysqld_t var_lib_t:dir { getattr search }; can_network(mysqld_t) can_ypbind(mysqld_t) # read config files r_dir_file(initrc_t, mysqld_etc_t) allow mysqld_t { etc_t etc_runtime_t }:{ file lnk_file } { read getattr }; allow mysqld_t etc_t:dir search; read_sysctl(mysqld_t) can_unix_connect(sysadm_t, mysqld_t) # for /root/.my.cnf - should not be needed allow mysqld_t sysadm_home_dir_t:dir search; allow mysqld_t sysadm_home_t:file { read getattr }; ifdef(`logrotate.te', ` r_dir_file(logrotate_t, mysqld_etc_t) allow logrotate_t mysqld_db_t:dir search; allow logrotate_t mysqld_var_run_t:dir search; allow logrotate_t mysqld_var_run_t:sock_file write; can_unix_connect(logrotate_t, mysqld_t) ') ifdef(`user_db_connect', ` allow userdomain mysqld_var_run_t:dir search; allow userdomain mysqld_var_run_t:sock_file write; ') ifdef(`daemontools.te', ` domain_auto_trans( svc_run_t, mysqld_exec_t, mysqld_t) allow svc_start_t mysqld_t:process signal; svc_ipc_domain(mysqld_t) ')dnl end ifdef daemontools ifdef(`distro_redhat', ` allow initrc_t mysqld_db_t:dir create_dir_perms; # because Fedora has the sock_file in the database directory file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file) ') Dan, do you have any idea what's going on here? What could selinux be complaining about, if not /var/lib? Looks like the mysql is trying to look in the directory you are currently running in. allow mysqld_t home_root_t:dir search; So you attempted to run this app from the /root directory and then it tried to chroot but failed. If you add the above rule does it work? "So you attempted to run this app from the /root directory and then it tried to chroot but failed." I've run the start skript in /etc/init.d "If you add the above rule does it work?" Which rule do I have to add and how do I add rules? I have added your rule to /etc/selinux/targeted/src/policy/domains/program/mysqld.te I rebooted the machine, unfortunately with no success, sorry! What else do you need to know, to solve this problem? Btw. I have worked on another FC3 machine today. I installed mysql and mysql-server (with some perl packages, which these packages depend on) and it worked !! Is it possible, that I have misconfigured something? greets Boris Well the AVC message you gave above says that mysql went searching for something in the root directory. So it is likely that something is screwed up. Is mysqld attempting to run as root? Here is my /etc/my.cf According to this file, it tries to run as user mysql. How can I check, which user it actually uses? # cat /etc/my.cnf [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock [mysql.server] user=mysql basedir=/var/lib [safe_mysqld] err-log=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid Hi, I have spent some time learning a bit about selinux. The proble here seems to be the directory /var/lib: $ ls -lZ /var | grep lib drwxr-xr-x root root system_u:object_r:home_root_t lib This directory also has the inode numer 240482, which is mentioned in the "avc denied" output: $ ls -li /var | grep lib 240482 drwxr-xr-x 29 root root 4096 5. Apr 23:11 lib I have found the following line in /etc/selinux/targeted/src/policy/file_contexts/file_contexts: /var/lib -d system_u:object_r:home_root_t The strange thing is the home_root_t domain, this directory belongs to!? Is this normal? I have never changed anything in this file. There are many other processes, which cannot access this directory,too: dhcpd and ntpd What would you suggest to do? greets Boris Btw.: The fact that mysql worked on another fc3 machine, as I've reported above, is only the have truth. The machine I was talking about has selinux disabled. Ok the problem is that you have a user account that is in the /var directory. This is screwing up the labeling. /var should be var_t. In FC3 we have a problem handling useraccounts with UID > 500 in the /var directory. Could you check if this is the case. Dan I have I user "ogo", for opengroupware.org with the uid 500 and the home directory /var/lib/opengroupware.org This might be the reason!! Is it enough to set the line in /etc/selinux/targeted/src/policy/file_contexts/file_contexts to the correct value, or do I have to "compile" the rules first? thanks Boris There's another strange thing: I understand, that the labeling is wrong, but how can the settings in /etc/selinux/targeted/src/policy/file_contexts/file_contexts be screwed up? Are these files edited automatically by any instance? Yes, genhomedircon generates these entries. Do you need to login or does the app need a login to ogo. IE Can you change the shell to /sbin/nologin I set ogo's home to /home/ogo (and created this dir before of course) and ran restorecon -R / It worked then for me. It's obviously not a mysql bug, but it's an ugly selinux bug. What's the procedure now in this case! greets Boris policycoreutils-1.18.1-2.12 Just went out to fedora-testing should fix this problem. Available on ftp://people.redhat.com:dwalsh/SELinux/FC3 |