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

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.

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!