Rainer Zocholl
2005-Apr-16 22:03 UTC
[Logcheck-devel] Bug#304978: Failed to get lockfile: /var/lock/logcheck.lock
Package: logcheck
Version: 1.2.37
Everytime(!) i upgrade debian logcheck i run into the error
that logcheck is trying to generate its lockfile at a
forbidden location.
The error message/mail is a bit missleading too.
When will that error be fixed? (I think i reported it already several
weeks a ago).
As logcheck never runs as "root", that error must
occur on every sane setup system, or?
Why do i not find any reports?
Is it a so common (dangerous) practise to allow every body to
litter "/var/lock" with its private lockfiles? Allowing everybody
to place a link to an unwanted file with the name of
a root lock file? So when root changes the (old) lock, it
changes the "unwanted" file too etc... or it's easy to block root
by placing a lock file with the same name root would test when
everybody can write to "/var/lock".
Decription:
After update logcheck i always get this error mail:
------------------------------------------------------------
Warning: If you are seeing this message, your log files may not have been
checked!
Details:
Failed to get lockfile: /var/lock/logcheck.lock
Check temporary directory:
declare -x HOME="/var/lib/logcheck"
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"
-----------------------------------------------------------------------
Solution:
you must edit the script(!) as logcheck has as security flaw
and tries to place it's lock file under /var/lock/ which is
-of course- only allowed for root!
You must create a directory "logcheck" under /var/lock/
mkdir /var/lock/logcheck
chown logcheck:logcheck /var/lock/logcheck
chmod 755 /var/lock/logcheck
# ll /var/lock/logcheck/
total 8
drwxr-xr-x 2 logcheck logcheck 4096 Apr 16 16:02 .
drwxr-xr-x 5 root root 4096 Apr 16 06:37 ..
And edit the script(!) like this:
[23:29:49]yoda:/etc/logcheck# diff -Nau /usr/sbin/logcheck
/usr/sbin/logcheck.ori
--- /usr/sbin/logcheck 2005-04-16 23:29:36.000000000 +0200
+++ /usr/sbin/logcheck.ori 2005-04-03 01:00:14.000000000 +0200
@@ -81,7 +81,7 @@
SORTUNIQ=0
SUPPORT_CRACKING_IGNORE=0
SYSLOGSUMMARY=0
-LOCKFILE="/var/lock/logcheck/logcheck"
+LOCKFILE="/var/lock/logcheck"
# Carry out the clean up tasks
cleanup() {
--------------------------------------------------------------
Maybe it would ease use a lot if "LOCKFILE" is
set in /etc/logcheck/logcheck.conf too?
HTH
maximilian attems
2005-Apr-18 07:31 UTC
Bug#304978: [Logcheck-devel] Bug#304978: Failed to get lockfile: /var/lock/logcheck.lock
On Sun, 17 Apr 2005, Rainer Zocholl wrote:> Everytime(!) i upgrade debian logcheck i run into the error > that logcheck is trying to generate its lockfile at a > forbidden location. > The error message/mail is a bit missleading too.on debian systems by default belows dir is writable for world: ls -ld /var/lock drwxrwxrwt 4 root root 4096 2005-04-18 09:02 /var/lock> When will that error be fixed? (I think i reported it already several > weeks a ago).care to add a pointer to that report? well your system seems broken, you can fix its permissions easily. [further rant snipped]> Is it a so common (dangerous) practise to allow every body to > litter "/var/lock" with its private lockfiles? Allowing everybody > to place a link to an unwanted file with the name of > a root lock file? So when root changes the (old) lock, it > changes the "unwanted" file too etc... or it's easy to block root > by placing a lock file with the same name root would test when > everybody can write to "/var/lock".well it's a bit hard to follow aboves flow. i try to summarize * if /var/lock is not world writable, one should have a dir below for one owns needs. * if /var/lock is world writable, one could block logcheck runs.> Decription: > > After update logcheck i always get this error mail: > > ------------------------------------------------------------ > > Warning: If you are seeing this message, your log files may not have been > checked! > > Details: > Failed to get lockfile: /var/lock/logcheck.lock > > Check temporary directory: > > declare -x HOME="/var/lib/logcheck" > 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" > > -----------------------------------------------------------------------that mail is pretty clear. why is it misleading?> Solution: > > you must edit the script(!) as logcheck has as security flaw > and tries to place it's lock file under /var/lock/ which is > -of course- only allowed for root!wrong assumption for any sarge default install.> You must create a directory "logcheck" under /var/lock/ > > mkdir /var/lock/logcheck > chown logcheck:logcheck /var/lock/logcheck > chmod 755 /var/lock/logchecktodd what do you think about that dir? sounds ok for me, but i don't get why you paranoid guy show your logcheck run to world, why not use 750 above??> And edit the script(!) like this: > > > [23:29:49]yoda:/etc/logcheck# diff -Nau /usr/sbin/logcheck /usr/sbin/logcheck.ori > --- /usr/sbin/logcheck 2005-04-16 23:29:36.000000000 +0200 > +++ /usr/sbin/logcheck.ori 2005-04-03 01:00:14.000000000 +0200 > @@ -81,7 +81,7 @@ > SORTUNIQ=0 > SUPPORT_CRACKING_IGNORE=0 > SYSLOGSUMMARY=0 > -LOCKFILE="/var/lock/logcheck/logcheck" > +LOCKFILE="/var/lock/logcheck" > > # Carry out the clean up tasks > cleanup() {hehe, you diffed in the wrong order. but anyway that part is clear.> -------------------------------------------------------------- > > > Maybe it would ease use a lot if "LOCKFILE" is > set in /etc/logcheck/logcheck.conf too?no, that file is already long enough, we don't want stupid config options for the user. that should just work on runtime. -- maks ps i don't get your nospam stuff, perhaps you'll read your bug report.
Debian Bug Tracking System
2005-Apr-19 04:18 UTC
[Logcheck-devel] Bug#304978: marked as done (Failed to get lockfile: /var/lock/logcheck.lock)
Your message dated Tue, 19 Apr 2005 00:02:12 -0400 with message-id <E1DNjwC-0002G1-00 at newraff.debian.org> and subject line Bug#304978: fixed in logcheck 1.2.38 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 16 Apr 2005 22:05:01 +0000>From UseNet-Posting-Nospam-74308- at zocki.toppoint.de Sat Apr 16 15:05:01 2005Return-path: <UseNet-Posting-Nospam-74308- at zocki.toppoint.de> Received: from archer.toppoint.de (mail.toppoint.de) [195.244.243.1] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DMvPQ-0006Ev-00; Sat, 16 Apr 2005 15:05:01 -0700 Received: (from uucp at localhost) by mail.toppoint.de (8.11.7p1+Sun/8.11.7) id j3GM4w301033 for submit at bugs.debian.org; Sun, 17 Apr 2005 00:04:58 +0200 (MEST)>Received: by zocki.toppoint.de (CrossPoint/FreeXP v3.40 RC3 (EMS) @ 3108030130 R/C6515);17 Apr 2005 00:03:55 +0200 Date: 17 Apr 2005 00:03:00 +0200 From: Rainer Zocholl <UseNet-Posting-Nospam-74308- at zocki.toppoint.de> To: <submit at bugs.debian.org> Message-ID: <9V3Nq436gjB at zocki.toppoint.de> Subject: Failed to get lockfile: /var/lock/logcheck.lock X-Mailer: CrossPoint/FreeXP v3.40 RC3 (EMS) @ 3108030130 R/C6515 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Organization: http://www.toppoint.de X-ZC-Telefon: V+49-431-5606-550Q V+49-431-562136Q X-XP-Version: CrossPoint/FreeXP v3.40 RC3 (EMS) @ 3108030130 R/C6515 X-RFC-Converter: E-UUZ/II [FreeXP v3.40.1a RC3] @ 200405292345 Received: from zocki.toppoint.de by archer.toppoint.de; Sun, 17 Apr 2005 00:04 MES Content-Type: text/plain; charset=US-ASCII Delivered-To: submit at bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-7.3 required=4.0 tests=BAYES_00,HAS_PACKAGE, MSGID_FROM_MTA_HEADER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: logcheck Version: 1.2.37 Everytime(!) i upgrade debian logcheck i run into the error that logcheck is trying to generate its lockfile at a forbidden location. The error message/mail is a bit missleading too. When will that error be fixed? (I think i reported it already several weeks a ago). As logcheck never runs as "root", that error must occur on every sane setup system, or? Why do i not find any reports? Is it a so common (dangerous) practise to allow every body to litter "/var/lock" with its private lockfiles? Allowing everybody to place a link to an unwanted file with the name of a root lock file? So when root changes the (old) lock, it changes the "unwanted" file too etc... or it's easy to block root by placing a lock file with the same name root would test when everybody can write to "/var/lock". Decription: After update logcheck i always get this error mail: ------------------------------------------------------------ Warning: If you are seeing this message, your log files may not have been checked! Details: Failed to get lockfile: /var/lock/logcheck.lock Check temporary directory: declare -x HOME="/var/lib/logcheck" 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" ----------------------------------------------------------------------- Solution: you must edit the script(!) as logcheck has as security flaw and tries to place it's lock file under /var/lock/ which is -of course- only allowed for root! You must create a directory "logcheck" under /var/lock/ mkdir /var/lock/logcheck chown logcheck:logcheck /var/lock/logcheck chmod 755 /var/lock/logcheck # ll /var/lock/logcheck/ total 8 drwxr-xr-x 2 logcheck logcheck 4096 Apr 16 16:02 . drwxr-xr-x 5 root root 4096 Apr 16 06:37 .. And edit the script(!) like this: [23:29:49]yoda:/etc/logcheck# diff -Nau /usr/sbin/logcheck /usr/sbin/logcheck.ori --- /usr/sbin/logcheck 2005-04-16 23:29:36.000000000 +0200 +++ /usr/sbin/logcheck.ori 2005-04-03 01:00:14.000000000 +0200 @@ -81,7 +81,7 @@ SORTUNIQ=0 SUPPORT_CRACKING_IGNORE=0 SYSLOGSUMMARY=0 -LOCKFILE="/var/lock/logcheck/logcheck" +LOCKFILE="/var/lock/logcheck" # Carry out the clean up tasks cleanup() { -------------------------------------------------------------- Maybe it would ease use a lot if "LOCKFILE" is set in /etc/logcheck/logcheck.conf too? HTH --------------------------------------- Received: (at 304978-close) by bugs.debian.org; 19 Apr 2005 04:09:42 +0000>From katie at ftp-master.debian.org Mon Apr 18 21:09:42 2005Return-path: <katie at ftp-master.debian.org> Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DNk3R-0004vh-00; Mon, 18 Apr 2005 21:09:42 -0700 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DNjwC-0002G1-00; Tue, 19 Apr 2005 00:02:12 -0400 From: Todd Troxell <ttroxell at debian.org> To: 304978-close at bugs.debian.org X-Katie: $Revision: 1.55 $ Subject: Bug#304978: fixed in logcheck 1.2.38 Message-Id: <E1DNjwC-0002G1-00 at newraff.debian.org> Sender: Archive Administrator <katie at ftp-master.debian.org> Date: Tue, 19 Apr 2005 00:02:12 -0400 Delivered-To: 304978-close at bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: X-CrossAssassin-Score: 3 Source: logcheck Source-Version: 1.2.38 We believe that the bug you reported is fixed in the latest version of logcheck, which is due to be installed in the Debian FTP archive: logcheck-database_1.2.38_all.deb to pool/main/l/logcheck/logcheck-database_1.2.38_all.deb logcheck_1.2.38.dsc to pool/main/l/logcheck/logcheck_1.2.38.dsc logcheck_1.2.38.tar.gz to pool/main/l/logcheck/logcheck_1.2.38.tar.gz logcheck_1.2.38_all.deb to pool/main/l/logcheck/logcheck_1.2.38_all.deb logtail_1.2.38_all.deb to pool/main/l/logcheck/logtail_1.2.38_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 304978 at bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Todd Troxell <ttroxell at debian.org> (supplier of updated logcheck package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster at debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.7 Date: Monday, 18 Apr 2005 23:45:00 -0500 Source: logcheck Binary: logcheck logtail logcheck-database Architecture: source all Version: 1.2.38 Distribution: unstable Urgency: low Maintainer: Debian logcheck Team <logcheck-devel at lists.alioth.debian.org> Changed-By: Todd Troxell <ttroxell at debian.org> Description: logcheck - Mails anomalies in the system logfiles to the administrator logcheck-database - A database of system log rules for the use of log checkers logtail - Print log file lines that have not been read Closes: 30088 295352 297995 302678 303176 304978 Changes: logcheck (1.2.38) unstable; urgency=low . maks: * Generalise postfix rule concerning network_biopair_interop. * Add rule for ntp message about valid/infalid peers. (Closes #303661) * Improve rules .PHONY target + add checkpo rule for the translation check. * Add help target to debian/rules documenting the syntax. jamie: * Add rule in violations.ignore.d/logcheck-postfix for postgrey (Closes: #30088) * Modify bind notify rule for bind 9.3.x (Closes: #303176) * Add various workstation kernel/udev rules for removable devices (Closes: #297995) * Modify rsync rule to match module names with '.', '-' and '_'. Thanks to SATOH Fumiyasu <fumiya at samba.gr.jp> for the patch (Closes: #295352) * Add nagios rule for UNKNOWN state service notification. * Modify postfix anvil rule for 'max connection' statistics messages to match smtps connections too. * Add new rules for policyd, a postfix policy daemon. * Add more postfix rules for certificate verification failure messages. * Add new rules for postfix scache (connection cache server). * Add rule for bind 9.3 'unexpected RCODE' messages. * Modify dnsmasq rule to match '/var/run/dnsmasq/resolv.conf' too. (Closes: #302678) todd: * Change lockfile location from /var/lock/logcheck to /var/lock/logcheck/logcheck (Thanks Rainer Zocholl) to avoid potential DoS condition. (Closes: #304978) * Make lockfile debug messages refer to the correct files. * Add note about dh_installlogcheck permissions. (See #302379) Files: a040986cd3efb1bc4b4b273ed4a0e635 703 admin optional logcheck_1.2.38.dsc d82a1faa4198dfa7900e518f8b3581d3 94121 admin optional logcheck_1.2.38.tar.gz 520c27384c61dc06f55a9698c42b7bbf 44576 admin optional logcheck_1.2.38_all.deb 70e46d26fa902d29668d16f1f7186af4 61472 admin optional logcheck-database_1.2.38_all.deb 6931679c977e9f6025ebbd4e7ccca586 27374 admin optional logtail_1.2.38_all.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCZH8R4u3oQ3FHP2YRAlR7AJ9f78c4NhflMsODo+Ov+/zR5bWNZACeJy+n 3OqLY4B4e4FxveJ3bkIPBUU=riHA -----END PGP SIGNATURE-----