Bug 1062147 (neil@squires.id.au) - Logcheck fails to read files on base install
Summary: Logcheck fails to read files on base install
Keywords:
Status: CLOSED CANTFIX
Alias: neil@squires.id.au
Product: Fedora
Classification: Fedora
Component: logcheck
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Runge
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1120828 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-06 10:18 UTC by Neil Squires
Modified: 2017-01-28 15:22 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-02-08 08:19:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Neil Squires 2014-02-06 10:18:28 UTC
Description of problem: When installing Logcheck as a package, the installation does not provide a program that will run


Version-Release number of selected component (if applicable):logcheck 1.3.14

How reproducible: Always


Steps to Reproduce:
1. Install a base gnome version of Fedora 20
2. yum -y install logcheck
3. either
A: open a terminal and run the command logcheck and the error will appear 
or 
B: Configure logcheck to send mail to a mail account and run logcheck. In the email file you will find:

Actual results:
Warning: If you are seeing this message, your log files may not have been
checked!

Details:
Could not run logtail or save output

Check temporary directory: /tmp/logcheck.R1lWkA

Also verify that the logcheck user can read all files referenced in
/etc/logcheck/logcheck.logfiles!

declare -x HOME="/var/lib/logcheck"
declare -x LANG="en_AU.UTF-8"
declare -x LOGNAME="logcheck"
declare -x MAILTO="root"
declare -x OLDPWD
declare -x PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
declare -x PWD="/var/lib/logcheck"
declare -x SHELL="/bin/sh"
declare -x SHLVL="2"
declare -x USER="logcheck"
declare -x XDG_RUNTIME_DIR="/run/user/989"
declare -x XDG_SESSION_ID="140"


Expected results:
Logcheck runs correctly and send you a file with the errors that the system is configured to report. This should be regardless of the logging system being used.


Additional info:
A check of the logfiles shows that the default installation for logcheck does not modify the groups for the /var/log/messages and /var/log/secure files to include the user or group logcheck. ls -la shows the following permissions:

$ls -la /var/log
total 8056
drwxr-xr-x. 18 root   root               4096 Feb  4 18:53 .
drwxr-xr-x. 21 root   root               4096 Feb  3 19:39 ..
drwxr-xr-x.  2 root   root               4096 Jan 25 16:07 anaconda
drwxr-x---.  2 root   root               4096 Jan 16 21:32 audit
-rw-r--r--.  1 root   root                  0 Feb  4 18:53 boot.log
-rw-------.  1 root   utmp               1920 Feb  2 22:35 btmp
-rw-------.  1 root   utmp               3072 Jan 28 21:08 btmp-20140201
drwxr-xr-x.  2 chrony chrony             4096 Aug  9 18:33 chrony
drwxr-xr-x.  2 root   root               4096 Sep 16 19:05 cluster
-rw-r--r--.  1 root   root              45711 Feb  6 19:02 cron
-rw-r--r--.  1 root   root               9534 Jan 26 03:37 cron-20140126
-rw-r--r--.  1 root   root              87062 Feb  3 07:29 cron-20140203
drwxr-xr-x.  2 lp     sys                4096 Feb  3 07:29 cups
drwx--x--x.  2 root   gdm                4096 Feb  3 19:39 gdm
drwxr-xr-x.  2 root   root               4096 Jan  3 22:10 glusterfs
-rw-------.  1 root   root               1212 Jan 25 18:27 grubby
drwxr-sr-x+  3 root   systemd-journal    4096 Jan 25 16:41 journal
-rw-r--r--.  1 root   root             292292 Feb  6 19:06 lastlog
drwx------.  6 root   root               4096 Jan 21 07:59 libvirt
-rw-------.  1 root   root              53987 Feb  6 19:26 maillog
-rw-------.  1 root   root                  0 Jan 25 15:59 maillog-20140126
-rw-------.  1 root   root                  0 Jan 26 03:37 maillog-20140203
-rw-------.  1 root   root             750535 Feb  6 19:29 messages
-rw-------.  1 root   root             875874 Jan 26 03:01 messages-20140126
-rw-------.  1 root   root            6033470 Feb  3 07:28 messages-20140203
drwxr-xr-x.  3 root   root               4096 Jan 25 15:45 pluto
drwx------.  2 root   root               4096 Aug  1  2013 ppp
drwxr-xr-x.  2 root   root               4096 Jan 25 17:29 prelink
-rw-r--r--.  1 root   root               1040 Dec  6 07:52 README
drwx------.  3 root   root               4096 Dec 11 01:56 samba
-rw-------.  1 root   root              12215 Feb  6 19:06 secure
-rw-------.  1 root   root              20643 Jan 25 21:01 secure-20140126
-rw-------.  1 root   root              21952 Feb  3 07:01 secure-20140203
drwx------.  2 root   root               4096 Aug 13 13:11 speech-dispatcher
-rw-r--r--.  1 root   root               2876 Feb  3 19:39 spice-vdagent.log
-rw-------.  1 root   root                  0 Feb  3 07:29 spooler
-rw-------.  1 root   root                  0 Jan 25 15:59 spooler-20140126
-rw-------.  1 root   root                  0 Jan 26 03:37 spooler-20140203
drwxr-x---.  2 root   root               4096 Dec 20 05:11 sssd
-rw-------.  1 root   root                  0 Jan 25 15:41 tallylog
drwxr-xr-x.  2 root   root               4096 Aug  4  2013 vbox
-rw-rw-r--.  1 root   utmp              42624 Feb  6 19:06 wtmp
-rw-r--r--.  1 root   root              19458 Feb  3 19:39 Xorg.0.log
-rw-r--r--.  1 root   root              19457 Feb  3 06:05 Xorg.0.log.old
-rw-r--r--.  1 root   root               6792 Jan 25 20:12 Xorg.1.log
-rw-------.  1 root   root              29742 Feb  4 06:02 yum.log

Those are the only two files the default configuration reads. Both of these files don't have permissions to be read by logcheck.

In addition, with the migration to systemd journal, how useful is logcheck?

The first part of the problem could be solved by adding logwatch to the root group (not really a good idea). The other alternative is to chown the log and secure files to root.wheel and add logwatch to the wheel group. second alternative is to chown root.logwatch to the files and chmod 640 to the two files. The third alternate is to chmod the files to 604.

At this point I have done neither.

The selinux permissions have not been checked either. This is very similar to a bug I reported in Fedora 16 (worked ok in 17 and I have just upgraded).

Comment 1 Matthias Runge 2014-02-08 08:19:33 UTC
Sadly, the situation has not changed. Those logfiles are not owned by any package, so I can not file a bug against that package to change ownership of those packages.

logcheck is useful, when you want to get emails from your system about unusual events.

I see, that the situation is not as good as it could or should be, but sadly, there's nothing I could do about this.

chown root:adm var/log/messages
and chmod 640 will still solve this.
logcheck is part of adm group.

You'd still need to add 
create 0640 root adm

to /etc/logrotate.d/syslog

Comment 2 Matthias Runge 2014-07-18 09:24:03 UTC
*** Bug 1120828 has been marked as a duplicate of this bug. ***


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