Bug 844795 - selinux prevents mysqld from starting with non-standard datadir
selinux prevents mysqld from starting with non-standard datadir
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
17
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-31 15:35 EDT by Aaron Kaplan
Modified: 2013-08-01 00:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 00:59:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aaron Kaplan 2012-07-31 15:35:33 EDT
After an upgrade (via preupgrade) from F15 to F17, mysqld stopped working. In /etc/my.cnf, datadir is set to /foo/data/mysql. I see the following in the system log:

Jul 31 14:48:23 localhost kernel: [   51.769983] type=1400 audit(1343760503.935:5): avc:  denied  { getattr } for  pid=1766 comm="mysqld" path="/foo" dev="sda4" ino=2 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=dir

/foo/data/mysql has the mysqld_db_t context, but /foo does not, so selinux is (correctly) denying access to /foo.

Bug #547485, which is mentioned in a comment in /usr/lib/systemd/system/mysqld.service, looks like it could be related. Maybe the --basedir workaround no longer works?
Comment 1 Tom Lane 2012-07-31 15:51:54 EDT
I don't think this is a bug at all.  If you are going to select a nonstandard data directory, it's incumbent on you to make sure it has the correct permissions (including selinux context).  The same applies to its parent directories, since mysqld can't reach the data directory without searching the parents.

Bug #547485 is not related --- that has to do with the mysqld_safe script searching for the "logger" program, which it looks for in $PATH not the data directory.
Comment 2 Aaron Kaplan 2012-07-31 16:19:06 EDT
I don't claim to be an selinux expert, but in F15 mysqld was running fine with selinux enforcement enabled, despite the fact that only /foo/data/mysql, not its parents, had the mysqld_db_t context. How do I reconcile this with your assertion that "mysqld can't reach the data directory without searching the parents"?
Comment 3 Tom Lane 2012-07-31 17:01:13 EDT
(In reply to comment #2)
> I don't claim to be an selinux expert, but in F15 mysqld was running fine
> with selinux enforcement enabled, despite the fact that only
> /foo/data/mysql, not its parents, had the mysqld_db_t context. How do I
> reconcile this with your assertion that "mysqld can't reach the data
> directory without searching the parents"?

Well, I guess the salient question is "what context did /foo have before, and what has it got now?"  I would not think that mysqld_db_t is a good idea, since that implies (at least to selinux) that mysqld can scribble on that directory.  All you want it to be able to do is read the parent directories.

For the normal data directory, selinux (presumably) grants read capability on contexts root_t, var_t, and var_lib_t to mysqld.  A quick hack solution might be to label the parent directories with one of these.

If you didn't change the labeling of the parent directories since F15, then this failure has to indicate that selinux-policy tightened up what it would allow mysqld to do with random directories.  Which doesn't seem like a bad idea in general.  I'm going to pass this one over to the selinux folk to see what their recommendations are for labeling a parent directory of a non-default mysql data directory.

(BTW, guys, I rather imagine that postgresql has got a similar problem, if whatever changed was a generic restriction for daemons and not something specific to mysqld.)
Comment 4 Fedora End Of Life 2013-07-03 20:50:44 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

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 prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life.

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 5 Fedora End Of Life 2013-08-01 00:59:31 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.

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.