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?
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.
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"?
(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.)
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.
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.