Logrotate no longer reads symlinked configuration file due to non-root ownership

We are currently upgrading from Ubuntu 12.04 LTS to 14.04 LTS on our ruby on rails application servers, and have noticed that the log files are no longer rotating.

On both machines we have a file /var/app-name/config/logrotate owned by our unix user deployer which contains a valid logrotate file as follows:

/var/app-name/log/*.log {
  daily
  rotate 365
  delaycompress
  compress
  dateext
  dateformat -%Y%m%d
  missingok
  copytruncate
}

This is then symlinked into the /etc/logrotate.d/ directory as app-name

On our Ubuntu 12.04 server we have logrotate 3.7.8 which runs just fine. It goes into the var/app-name/log/ directory and rotates all out log files

But on Ubuntu 14.04 server we have logrotate 3.8.7 which doesn't rotate the logfiles for our application.

When I debug this via sudo logrotate -d -f /etc/logrotate/.conf I get the following output:

Ignoring /etc/logrotate.d/app-name because the file owner is wrong (should be root).

Chasing this down in the code, it seems this change was added for the 3.8.x release stream: https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

If I change the ownership of the file symlinked to /var/app-name/config/logrotate to root then it starts to work again. But given this file is part of my application, and created by the capistrano deployment framework we use in this state, I'd rather not have to alter it's ownership, when it used to work just fine.

So are symlinked config files recommended / supported by logrotate ?

And if so, should it's refusal to use my file (owned by deployer) which is symlinked into the /etc/logrotate.d directory, be seen as a bug ?

Or is there another recommended approach for application-specific log rotation ?

(also asked on unix StackExchange)

phantomwhale

Posted 2014-08-06T02:16:27.893

Reputation: 201

Good question! I see that there was some discussion later on about checking against the username "root" instead of uid == 0, but also that didn't trigger the question why root ownership is required.

– agtoever – 2014-08-12T09:05:14.427

Answers

The problem is that a logrotate config file can run any command as root (using prerotate/postrotate stanzas). Therefore, you would effectively be giving your deployer user root privileges by giving it write access to files in /etc/logrotate.d/. So no, it's not a bug.

If you trust your deployer user, then I guess you could solve the problem by giving it sudo rights to copy files into /etc/logrotate.d/. Asssuming, of course, that the deployer user is not the same user that the web app is running as.

pelle

Posted 2014-08-06T02:16:27.893

Reputation: 896

Our approach had always been to prefer to symlink from directories external to the application into application files, such that each deploy not only pushes out the new application, but also any configuration file changes.

Even giving the deployer the rights to deploy code outside of the application directory violates this approach - but equally having to chown an application file to be root owned post-deploy feels like a bad thing (tm) too.

Perhaps the original approach therefore can no longer work nicely with logrotate 3.8.0+ – phantomwhale – 2014-09-02T01:56:45.937

2@phantomwhale Your original approach implicitly gave your deployer user full root privileges. That's not new in logrotate 3.8. If you want to restrict the deployer's rights while still allowing it to update the config, then I think you need to use something other than logrotate. – pelle – 2014-09-02T07:49:16.783

I realize that I'm kind of late to the party, but I was having a similar issue and thought I would share my solution.

My problems started when logrotate wouldn't read the configuration that I had written. I didn't want to deploy new configurations into a folder owned by root because I didn't want the deploy user to have root access to anything.

At first I tried to run logrotate as the deploy user, but it complained about having access to the state file at /var/lib/logrotate/state. Then I read the man page. You can specify the state file that logrotate uses! So, it seemed a better solution to me to set up a daily cron to execute logrotate as the deploy user with a custom state file. This way, no root access is needed by the deploy user or the application.

Here's how you specify the state file:

logrotate --state /path/to/status /path/to/custom_logrotate.conf

Now you can run logrotate as any user and configuration owner that you like!

dayer4b

Posted 2014-08-06T02:16:27.893

Reputation: 121