Bug 489038 - RFE: useful permissions on log files
RFE: useful permissions on log files
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: logrotate (Show other bugs)
12
All Linux
low Severity high
: ---
: ---
Assigned To: Jan Kaluža
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 554326
  Show dependency treegraph
 
Reported: 2009-03-06 16:17 EST by Bernie Innocenti
Modified: 2010-10-12 06:31 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 554326 (view as bug list)
Environment:
Last Closed: 2010-06-11 02:53:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bernie Innocenti 2009-03-06 16:17:07 EST
Making logs group readable and owned by a group such as adm would
make it easy to allow specific users to read the logs without
granting them full root privileges.   Debianesque systems
already work like this.

This could be achieved with

   create 0640 root adm
Comment 1 Bug Zapper 2009-06-09 07:57:49 EDT
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
Comment 2 Bernie Innocenti 2009-08-25 11:41:06 EDT
Such a change would most probably belong to rawhide.
Comment 3 Jan Ščotka 2009-08-26 10:28:04 EDT
In previous version it have same behaviour? So, it is RFE, or it is regression?
Comment 4 Bernie Innocenti 2009-10-04 21:02:40 EDT
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.
Comment 5 Bug Zapper 2009-11-16 04:51:08 EST
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
Comment 6 Karel Volný 2010-01-11 06:57:32 EST
ping, any progress on this?
Comment 7 Daniel Novotny 2010-01-11 07:59:07 EST
hello,
the change is straightforward, added in rawhide
(logrotate-3.7.8-7.fc13)
Comment 8 Féliciano Matias 2010-04-18 08:58:35 EDT
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 ?
Comment 9 Henrik Nordström 2010-04-18 19:09:49 EDT
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.
Comment 10 Henrik Nordström 2010-04-19 16:17:39 EDT
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.
Comment 11 Daniel Novotny 2010-04-20 06:42:06 EDT
hello,
if this can cause problems, do you want me to revert the change?
Comment 12 Henrik Nordström 2010-04-20 09:29:12 EDT
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.
Comment 13 Daniel Novotny 2010-04-20 09:46:58 EDT
change reverted in rawhide (logrotate-3.7.8-9.fc14), will do in F13 too
Comment 14 Fedora Update System 2010-04-20 10:05:50 EDT
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
Comment 15 Fedora Update System 2010-04-30 19:45:04 EDT
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.
Comment 16 Fedora Admin XMLRPC Client 2010-06-10 06:42:47 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 17 Henrik Nordström 2010-06-10 06:49:55 EDT
Is there a reason to why this report is kept open?
Comment 18 Karel Volný 2010-06-10 09:00:34 EDT
(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
Comment 19 Jan Kaluža 2010-06-11 02:53:05 EDT
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.
Comment 20 Bernie Innocenti 2010-06-11 08:23:28 EDT
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.
Comment 21 Karel Volný 2010-10-12 06:31:23 EDT
(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

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