Description of problem: Historically, the mysqld_safe script has executed mysqld as a subprocess (fork/exec). We would like to change it to just exec mysqld, so as to simplify matters for systemd integration, but the selinux rules interfere. It looks like no context transition occurs, so the mysqld_safe_t rules continue to be applied to mysqld. I also find that if systemd is trying to pass an open socket to mysqld, that socket gets replaced by a "/null" something-or-other during the exec. This is undesirable as well. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.9.16-34.fc15.noarch How reproducible: 100% Steps to Reproduce: See discussion in bug #714426, particularly https://bugzilla.redhat.com/show_bug.cgi?id=714426#c65 Additional info: Although we don't intend to release mysqld native systemd integration in F15, I'd appreciate it if this could be changed in both F15 and rawhide, so that I can test this version of mysql on my F15 box. However, that would require making the selinux rules allow both styles, which might or might not be workable from your standpoint.
Looks like it should work. domtrans_pattern(mysqld_safe_t, mysqld_exec_t, mysqld_t) Is written in policy now. Is there a package available I could run? Or is there a system I can get access to, in order to see what is going on?
(In reply to comment #1) > Is there a package available I could run? There are assorted attachments to bug #714426 but assembling the right pieces into a package takes a bit of work. Would the audit log tell you what you want to know?
Yes it would help.
Created attachment 515612 [details] patch that attempts to add socket activation feature to mysql OK, here is a test case you can play with. Apply this patch to mysql git HEAD, build and install RPMs (you need mysql-server, mysql, mysql-libs), then do systemctl start mysqld.socket mysql -u root test This will put the system into a pretty busy loop of the mysqld server failing and being restarted (you might want to adjust the restart options in mysqld.service). I can detect two different problems: 1. Entries are being made in audit.log that show mysqld being refused access to the socket, apparently because selinux thinks it is mysqld_safe not mysqld. For example, type=AVC msg=audit(1311814995.081:117): avc: denied { getattr } for pid=3894 comm="rm" path="/var/lib/mysql/mysql.sock" dev=dm-1 ino=262583 scontext=system_u:system_r:mysqld_safe_t:s0 tcontext=system_u:object_r:mysqld_db_t:s0 tclass=sock_file The scontext here is definitely not as expected. 2. lsof on the mysqld process shows mysqld 20285 mysql 0u CHR 1,3 0t0 4348 /dev/null mysqld 20285 mysql 1u REG 253,1 140246 262976 /var/log/mysqld.log mysqld 20285 mysql 2u REG 253,1 140246 262976 /var/log/mysqld.log mysqld 20285 mysql 3w CHR 1,3 0t0 22 /null where FD3 is where the socket should have gotten passed. On reflection this might be an indication of mysqld trying to restore access to the socket after the AVC denials, hard to be sure without doing a lot of digging in the code. But /null seems a bit weird no?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.