Hide Forgot
There is no logrotate script for mysqld.log. And so it grows and grows and grows and grows...... hmmmm.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Not fixd
Is there anyone working on this?
Seems to be present in F15 also.
What log are we talking about? If you'd like to rotate the error log, mind that it is a complicated issue already discussed here several times, as well as in upstream. Please, see bug #180639, bug #72391 and http://bugs.mysql.com/bug.php?id=6061
It seems us mere mortals don't have access to bug 180639.
(In reply to comment #6) > It seems us mere mortals don't have access to bug 180639. Never mind, what is important, mysql-log-rotate script which is provided by upstream is not shipped in Fedora for years. The reason is that log rotation doesn't work well and it's not easy to fix it. Since it's preferred not to differ from upstream, the best place to discuss possible solution is the upstream bug tracker (http://bugs.mysql.com). Just a general hint: mysql error log shouldn't be much verbose. If you encounter problems with error log size, there will probably be something broken in your mysql configuration.
Created attachment 557274 [details] use correct path to log file in fedora It seems to work in current version, just a little patch to log file path is needed. I haven't found a variable that can be used instead of absolute path /var/log/mysqld.log, but since the same is used in my.cfg, I think it should be fine.
mysql-5.5.20-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mysql-5.5.20-1.fc16
mysql-5.5.20-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
In F16 at least, SELinux prevents mysqladmin run from logrotate from reading /root/.my.cnf: type=AVC msg=audit(1329214586.978:6545): avc: denied { getattr } for pid=11374 comm="mysqladmin" path="/root/.my.cnf" dev=vda2 ino=657252 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
Policy has this comment. # for /root/.my.cnf - should not be needed: userdom_read_user_home_content_files(mysqld_t)
Hm, if that's in the policy then why are we seeing the AVC message? I was first wondering if we could prevent mysqladmin from doing this when launched from logrotate, but I notice in the comments in mysql-log-rotate that touching that file is expected and required if the "root" database user has a password, which it typically should. So I think we have to allow it.
I have selinux-policy-3.10.0-75.fc16.noarch, but I don't seem to have the /root/.my.cnf label: [root@alfresco ~]# restorecon -v /root/.my.cnf [root@alfresco ~]# ls -lZ /root/.my.cnf -r--------. root root unconfined_u:object_r:admin_home_t:s0 /root/.my.cnf
I would have thought the rule in comment 12 allowed mysqld_t (the mysql daemon) access to user's files. But the AVC is about logrotate_t trying to access an admin file. Using sesearch I only see logrotate_t being allowed to access directories of that type. mimmi$ sudo sesearch --allow --source=logrotate_t --target=admin_home_t [sudo] password for root: Found 1 semantic av rules: allow logrotate_t file_type : dir { getattr search open } ; (Unless something is strange on my system. It might be. I don't get this to work at all. Instead I get a mail that /usr/bin/mysqladmin: connect to server at 'localhost' failed error: 'Access denied for user 'root'@'localhost' (using password: NO)' As if it wasn't even trying to use the .my.cnf. No AVC:s though.)
Does userdom_read_user_home_content_files(mysqld_t) cover admin_home_t?
> Does userdom_read_user_home_content_files(mysqld_t) cover admin_home_t? It is defined in /usr/share/selinux/devel/include/system/userdomain.if, and from what I can tell it only covers user_home_t and user_home_dir_t. And even if it did, it would allow mysqld_t access, not logrotate_t. So neither the process domain nor the file type applies to your AVC. Again, from what I understand.
It is probably best to add a mysqld_home_t and then label this for $HOME/.my.cnf and /root/.my.cnf Tom is there other content in the users homedir that mysqld should be allowed to read?
No, I think you've missed the point. This is *not* about adding new privileges for mysqld. As stated in comment #15, the issue here is that we added a logrotate script which requires that logrotate be able to call mysqladmin, and mysqladmin needs a password from ~root/.my.cnf so that it can talk to the mysql daemon. But mysqld doesn't need to read that file. It's not clear to me whether we should just add the extra privilege for logrotate_t, or introduce extra mechanism to detect logrotate spawning mysqladmin. Your call on that.
Well currently we are too loose, since we allow mysql to read user_home_t but not admin_home_t. I have just updated policy in F17 to add a label myqsld_home_t to both /root/.my.cnf and ~/.my.cnf and now am allowing mysql to only read those files. We can back port this fix to F16. Then I can allow logrotate_t to read this content also.
Strange, I can't get any AVC using mysql-5.5.20-1.fc16 and selinux-policy-3.10.0-75.fc16. But during playing with it, I found that we should probably un-comment "create 600 mysql mysql" line in /etc/logrotate.d/mysql, since the log file is not created when using /etc/logrotate.d/mysql alone, like this: [me@local]# logrotate /etc/logrotate.d/mysql It works fine when we rotate all log files, because "create" is set in /etc/logrotate.conf.
But Daniel, why do you want to give those files a mysqld type? Mysqld should not have access to them.
Well I can give them a type that logrotate can have access to but not mysqld.
(In reply to comment #21) > But during playing with it, I found that we should probably un-comment "create > 600 mysql mysql" line in /etc/logrotate.d/mysql, since the log file is not > created when using /etc/logrotate.d/mysql alone, like this: > [me@local]# logrotate /etc/logrotate.d/mysql Hmm. It would be good to know why upstream has it commented out by default ...
(In reply to comment #23) > Well I can give them a type that logrotate can have access to but not mysqld. To me, that would make sense.
Created attachment 564059 [details] SELinux module to work around the problem In case it might help anyone, here is a small module I use until there is an official fix.
(In reply to comment #24) > Hmm. It would be good to know why upstream has it commented out by default ... MySQL daemon should create the file if doesn't exist, but in our configuration the daemon is running under mysql user and doesn't have enough privileges to create the log file in /var/log/ [1]. So we should probably un-comment the line in Fedora. [1] http://lists.mysql.com/mysql/226843
I've discussed disabling logrotate scripts with jkaluza and it seems we have two options: 1) comment all lines by prefixing them with '#' 2) disable a logrotate config file by renaming it with a suffix ".disabled". ad 2): If our mysql logrotate script will be installed as /etc/logrotate.d/mysqld.disabled, it won't be used by default and users would have to rename it to /etc/logrotate.d/mysqld to be working. But let's see what happens when we rename that file and then update mysql - there will be two files then: /etc/logrotate.d/mysqld.disabled and /etc/logrotate.d/mysqld, which is probably not very nice. We can get rid of creating this file by using a symlink instead of renaming: /etc/logrotate.d/mysqld -> /etc/logrotate.d/mysqld.disabled But I'm not sure now which solution is better, an ideas?
The two-files situation seems like it would be awfully confusing. I think commenting out is the most workable answer.
Now I found 3rd option, which is probably not the official way, but works - to change file mode to 000. Then logrotate prints: "Ignoring mysqld because of bad file mode." ... but still not sure if better than commenting out.
Am I missing something? Or is some discussion missing from the comments in this bugzilla? WHY do you want to disable the rotation? I thought the only thing we were waiting for was a selinux-policy that allowed the current configuration, and then everything would work.
Yeah, those last couple of comments are actually more relevant to bug #799735. We do need the selinux-policy fix, but it's become apparent that there are multiple reasons why the logrotate script might fail, so we're thinking we ought to disable it by default.
I see. Thanks for clarifying. (FWIW, I would also vote for commenting out, if it is to be disabled by default. RPM/YUM knows how to handle modified configuration files, so there would be no surprises of that kind.)
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.