This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 725480 - Please change policy to allow mysqld_safe_t to exec mysqld_t
Please change policy to allow mysqld_safe_t to exec mysqld_t
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
Depends On:
Blocks: 714426
  Show dependency treegraph
 
Reported: 2011-07-25 11:23 EDT by Tom Lane
Modified: 2015-02-17 08:49 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 08:49:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch that attempts to add socket activation feature to mysql (35.64 KB, patch)
2011-07-27 21:16 EDT, Tom Lane
no flags Details | Diff

  None (edit)
Description Tom Lane 2011-07-25 11:23:53 EDT
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.
Comment 1 Daniel Walsh 2011-07-25 11:41:08 EDT
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?
Comment 2 Tom Lane 2011-07-25 12:14:36 EDT
(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?
Comment 3 Daniel Walsh 2011-07-25 14:42:32 EDT
Yes it would help.
Comment 4 Tom Lane 2011-07-27 21:16:17 EDT
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?
Comment 5 Fedora End Of Life 2013-04-03 12:15:50 EDT
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
Comment 7 Fedora End Of Life 2015-01-09 11:43:51 EST
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.
Comment 8 Fedora End Of Life 2015-02-17 08:49:17 EST
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.

Note You need to log in before you can comment on or make changes to this bug.