Bug 547007 - No Logrotate Script for mysqld.log
No Logrotate Script for mysqld.log
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
16
All Linux
low Severity medium
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-13 01:11 EST by Eli Wapniarski
Modified: 2013-02-13 21:58 EST (History)
7 users (show)

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


Attachments (Terms of Use)
use correct path to log file in fedora (766 bytes, patch)
2012-01-24 12:07 EST, Honza Horak
no flags Details | Diff
SELinux module to work around the problem (352 bytes, text/plain)
2012-02-18 10:34 EST, Göran Uddeborg
no flags Details

  None (edit)
Description Eli Wapniarski 2009-12-13 01:11:53 EST
There is no logrotate script for mysqld.log. And so it grows and grows and grows and grows......

hmmmm.
Comment 1 Bug Zapper 2010-11-03 23:29:40 EDT
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
Comment 2 Eli Wapniarski 2010-11-04 01:12:55 EDT
Not fixd
Comment 3 Sandro Bonazzola 2011-02-02 02:15:17 EST
Is there anyone working on this?
Comment 4 Sandro Bonazzola 2011-05-10 08:20:08 EDT
Seems to be present in F15 also.
Comment 5 Honza Horak 2011-09-27 11:05:53 EDT
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
Comment 6 Göran Uddeborg 2011-09-27 11:56:01 EDT
It seems us mere mortals don't have access to bug 180639.
Comment 7 Honza Horak 2011-09-29 06:58:54 EDT
(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.
Comment 8 Honza Horak 2012-01-24 12:07:42 EST
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.
Comment 9 Fedora Update System 2012-01-27 12:21:52 EST
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
Comment 10 Fedora Update System 2012-02-08 17:53:15 EST
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.
Comment 11 Orion Poplawski 2012-02-14 18:44:35 EST
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
Comment 12 Daniel Walsh 2012-02-15 14:27:22 EST
Policy has this comment.

# for /root/.my.cnf - should not be needed:
userdom_read_user_home_content_files(mysqld_t)
Comment 13 Tom Lane 2012-02-15 14:52:31 EST
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.
Comment 14 Orion Poplawski 2012-02-15 15:54:11 EST
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
Comment 15 Göran Uddeborg 2012-02-15 16:04:01 EST
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.)
Comment 16 Orion Poplawski 2012-02-15 16:08:40 EST
Does userdom_read_user_home_content_files(mysqld_t) cover admin_home_t?
Comment 17 Göran Uddeborg 2012-02-15 17:07:54 EST
> 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.
Comment 18 Daniel Walsh 2012-02-16 09:52:53 EST
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?
Comment 19 Tom Lane 2012-02-16 10:04:17 EST
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.
Comment 20 Daniel Walsh 2012-02-16 10:12:14 EST
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.
Comment 21 Honza Horak 2012-02-16 10:40:51 EST
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.
Comment 22 Göran Uddeborg 2012-02-16 13:57:16 EST
But Daniel, why do you want to give those files a mysqld type?  Mysqld should not have access to them.
Comment 23 Daniel Walsh 2012-02-16 17:59:49 EST
Well I can give them a type that logrotate can have access to but not mysqld.
Comment 24 Tom Lane 2012-02-16 20:16:13 EST
(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 ...
Comment 25 Göran Uddeborg 2012-02-17 13:49:45 EST
(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.
Comment 26 Göran Uddeborg 2012-02-18 10:34:01 EST
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.
Comment 27 Honza Horak 2012-02-23 04:08:57 EST
(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
Comment 28 Honza Horak 2012-03-07 09:40:21 EST
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?
Comment 29 Tom Lane 2012-03-07 09:57:44 EST
The two-files situation seems like it would be awfully confusing.  I think commenting out is the most workable answer.
Comment 30 Honza Horak 2012-03-07 10:17:09 EST
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.
Comment 31 Göran Uddeborg 2012-03-07 14:30:42 EST
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.
Comment 32 Tom Lane 2012-03-07 15:00:37 EST
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.
Comment 33 Göran Uddeborg 2012-03-07 15:33:03 EST
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.)
Comment 34 Fedora End Of Life 2013-01-16 21:03:29 EST
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
Comment 35 Fedora End Of Life 2013-02-13 21:58:55 EST
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.

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