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

logrotatepermissionsUbuntu

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)

Best Answer

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.

Related Question