Bug 489038

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Such a change would most probably belong to rawhide.

In previous version it have same behaviour? So, it is RFE, or it is regression?

It's an RFE.  I've been enjoying the proposed behavior for 6 months on my Fedora system.

Besides the change to the logrotate configuration, we'd also have to change permissions for subdirectories owned by specific packages, for example /var/log/prelink.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

ping, any progress on this?

hello,
the change is straightforward, added in rawhide
(logrotate-3.7.8-7.fc13)

This change don't make squid happy.
After logrotate, I got in /var/log/message :

Apr 18 14:54:04 one (squid): Cannot open /var/log/squid/access.log: (13) Permission denied
Apr 18 14:54:04 one (squid): Cannot open /var/log/squid/access.log: (13) Permission denied
Apr 18 14:54:04 one squid[10128]: Squid Parent: child process 10130 exited with status 1
Apr 18 14:54:04 one squid[10128]: Squid Parent: child process 10130 exited with status 1
[root@one ~]# Apr 18 14:54:07 one squid[10128]: Squid Parent: child process 10215 started
Apr 18 14:54:07 one squid[10128]: Squid Parent: child process 10215 started
Apr 18 14:54:07 one (squid): Cannot open '/var/log/squid/access.log' for writing.#012#011The parent directory must be writeable by the#012#011user 'squid', which is the cache_effective_user#012#011set in squid.conf.
Apr 18 14:54:07 one (squid): Cannot open '/var/log/squid/access.log' for writing.#012#011The parent directory must be writeable by the#012#011user 'squid', which is the cache_effective_user#012#011set in squid.conf.
Apr 18 14:54:07 one squid[10128]: Squid Parent: child process 10215 exited with status 1
Apr 18 14:54:07 one squid[10128]: Squid Parent: child process 10215 exited with status 1
Apr 18 14:54:10 one squid[10128]: Squid Parent: child process 10217 started
Apr 18 14:54:10 one squid[10128]: Squid Parent: child process 10217 started
Apr 18 14:54:10 one (squid): Cannot open '/var/log/squid/access.log' for writing.#012#011The parent directory must be writeable by the#012#011user 'squid', which is the cache_effective_user#012#011set in squid.conf.
Apr 18 14:54:10 one (squid): Cannot open '/var/log/squid/access.log' for writing.#012#011The parent directory must be writeable by the#012#011user 'squid', which is the cache_effective_user#012#011set in squid.conf.
Apr 18 14:54:10 one squid[10128]: Squid Parent: child process 10217 exited with status 1
Apr 18 14:54:10 one squid[10128]: Squid Parent: child process 10217 exited with status 1
Apr 18 14:54:13 one squid[10128]: Squid Parent: child process 10219 started
Apr 18 14:54:13 one squid[10128]: Squid Parent: child process 10219 started


Before logrotate :
# ll /var/log/squid/
total 484
-rw-r-----. 1 squid squid 476284 18 avril 07:59 access.log
-rw-r-----. 1 squid squid   7487 18 avril 14:53 cache.log
-rw-r--r--. 1 squid squid    325 18 avril 14:53 squid.out

After logrotate :
# ll /var/log/squid/
total 60
-rw-r-----. 1 root  adm       0 18 avril 14:54 access.log
-rw-r-----. 1 squid squid 53202 18 avril 14:54 access.log-20100418.gz
-rw-r-----. 1 root  adm       0 18 avril 14:54 cache.log
-rw-r-----. 1 squid squid  1732 18 avril 14:54 cache.log-20100418.gz
-rw-r--r--. 1 squid squid   325 18 avril 14:53 squid.out


Is it "bug" in logrotate or should we adjust /etc/logrotate.d/squid ?

This change breaks any package which assumes logfiles either get recreated with the same permissions or not at all. Not all logs are written by root.

As Squid maintainer I am fine with adding explicit create/nocreate statements to the squid logrotate definition.

One more comment. I do not think that forcing logrotate to a system wide default log file permissions is the right path for solving what this bug is about. The former default of "create" (with no arguments) addresses that nicely by automatically keeping any permissions the local admin have set to the existing log files. The new default will force the local admin to fix up each logrotate snipped to match local policy if that differs from using the "adm" group as a system wide log file group.

Imho this kind of change better belong in each individual package than logrotate itself, and then preferably in the the package settings in how it creates the log files (install or when not existing) and not in the log rotation.

hello,
if this can cause problems, do you want me to revert the change?

It's ultimately your call, but personally I do not think it's wise to change system wide default like this and as already noted in Comment #4 it's not a full solution to the original problem.

Imho the real solution to the original problem is to keep the standard logrotate "create" default as documented in logrotate documentation, and simply chgrp+chmod the log files as desired giving desired groups access to their relevant logs.

The question "can cause problems" is already answered I think. It obviously did cause problems for the squid package in Fedora. I have not audited the rest of fedora to tell if  there is any other packages which may suffer similar issuer, nor do I have any idea of how common the problem may be with third party packages site local logrotate definitions.

For Squid there is an update submitted for testing which adds an explicit create setting, making it independent of the system default.

change reverted in rawhide (logrotate-3.7.8-9.fc14), will do in F13 too

logrotate-3.7.8-8.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/logrotate-3.7.8-8.fc13

logrotate-3.7.8-8.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Is there a reason to why this report is kept open?

(In reply to comment #17)
> Is there a reason to why this report is kept open?    

I *think* because the update has been pushed to F13 while the report is for F12, so it didn't get closed automatically

Jan, please review the status

From my understanding it's WONTFIX, because Dan reverted that change and currently it's not used in any package and from comments above it's clear, that this change is problematic and would have probably big impact on other packages which assume logfiles are recreated with the same permissions.

Indeed, Debian/Ubuntu do achieve the feature requested in this bug by setting a default in rsyslog.conf:

 $FileOwner syslog
 $FileGroup adm
 $FileCreateMode 0640
 $DirCreateMode 0755
 $Umask 0022
 $PrivDropToUser syslog
 $PrivDropToGroup syslog

I'm reassigning the bug to the rsyslog component, but I don't seem to have permissions to reopen it. Please, reopen it if you think this is the correct way to do it.

(In reply to comment #20)
> I'm reassigning the bug to the rsyslog component, but I don't seem to have
> permissions to reopen it. Please, reopen it if you think this is the correct
> way to do it.

I don't think reopening this would be effective - if you have another proposal what to do about permissions that concerns another component then please file a new RFE for that component, clearly stating what change do you consider the best