Bug#304978: [Logcheck-devel] Bug#304978: Failed to get lockfile: /var/lock/logcheck.lock

Mon Apr 18 21:49:00 UTC 2005

debian at sternwelten.at(maximilian attems)  18.04.05 09:31

>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
>well your system seems broken, you can fix its permissions easily.

Uups. Sorry, that would explain why only i have that problem...

But meanwhile i found others had that problem too.
simply by searching for the error message at google ;-)
(some things are too simple)
(But no helpful answers like yours, thanks.).

>> 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.

Yes.

>* if /var/lock is world writable, one could block logcheck runs.

ACK, i assume so. Maybe that's a wanted side effect! (But with logcheck?)
How does "lock"-check reacts when it finds a lockfile not
owned by the current user?
I assume logcheck will issue only the warning mail, or?
So an attacker wins time to cleanup the logsfiles.
If that is wanted, it's Ok to place the lock into "/var/lock".

I think the problem started when logcheck where run by "logcheck"
and not by root anymore (but that was a very wise decission).

>> 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?

Because "/var/lock/logcheck.lock" does not occure anywhere
in the script.
Only "/var/lock/logcheck". The ".lock" is added by 
the lockfile program. That's not "transparent", IOW "not clear".

second:
What is the meaning/context of the line
"Check temporary directory:"?
How is it related to the "declares" below?
I don see the path to the lock file there nor
a "tmp" only a "home".
(pardon my nitpitting, but i hope they will be helpful, not annoying)

>> 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.

Hm, maybe that change was done by "hardening" the system?
I see that (all) other "non root" programs generates
a subdirectory below "/var/lock/", so have no problem with
that paranoid setting.
Currently logcheck is the only programm having trouble with that
config, so i assuemd an error there, not in my box, sorry.

# ll /var/lock/
total 20
drwxr-xr-x   5 root     root     4096 Apr 18 06:36 .
drwxr-xr-x  17 root     root     4096 Mar 14 15:39 ..
drwxr-xr-x   2 logcheck logcheck 4096 Apr 18 23:02 logcheck
drwxrwxr-x   2 list     list     4096 Apr 18 23:00 mailman
drwxr-xr-x   2 root     root     4096 Apr 18 23:00 mrtg

I don't know how your /var/run looks.
The one here too has no "stick bit" but subdirectories
for each "non root" program:

# ll /var/run/
total 124
drwxr-xr-x  18 root      root     4096 Apr 17 20:22 .
drwxr-xr-x  17 root      root     4096 Mar 14 15:39 ..
-rw-r--r--   1 root      root        5 Apr 17 06:36 apache-ssl.pid
-rw-r--r--   1 root      root        4 Apr 14 17:06 atd.pid
drwxr-xr-x   2 clamav    clamav   4096 Apr 14 17:05 clamav
-rw-r--r--   1 root      root        4 Apr 14 17:06 crond.pid
----------   1 root      root        0 Apr 14 17:06 crond.reboot
drwx------   2 fetchmail nogroup  4096 Feb 18 18:52 fetchmail
drwxr-xr-x   2 freerad   freerad  4096 Apr 14 17:06 freeradius
srwx------   1 www-data  root        0 Apr 17 06:36 gcache_port
drwxr-xr-x   2 identd    nogroup  4096 Apr 14 17:06 identd
-rw-r--r--   1 root      root        4 Apr 14 17:05 inetd.pid
-rw-r--r--   1 root      root        4 Apr 14 17:05 klogd.pid
drwxr-xr-x   2 logcheck  logcheck 4096 Feb 23 21:03 logcheck
drwxr-xr-x   2 list      list     4096 Apr 14 17:06 mailman
-rw-r--r--   1 root      root        3 Apr 14 17:06 ntpd.pid
drwxr-xr-x   2 root      root     4096 Apr 14 17:06 proftpd

But of course: There is no sense the a program
can ever the change PID of an other program.

An other "woody" install:
msi:~# ls -al /var/lock
total 24
drwxrwxrwt    6 root     root         4096 Apr 18 23:02 .
drwxr-xr-x   25 root     root         4096 Dec 14 00:33 ..
drwxr-xr-x    2 www-data www-data     4096 Mar 22  2004 DAV
drwx------    2 root     root         4096 Jan  8 23:43 lvm
drwxr-xr-x    2 root     root         4096 Apr 18 23:10 mrtg
drwxr-xr-x    2 root     root         4096 Apr 18 19:18 subsys

An "IPcop" paraniod firewall installation:

# ls -al /var/lock
drwxr-xr-x   3 root root 4096 2005-04-18 23:15 .
drwxr-xr-x  12 root root 4096 2004-09-25 23:05 ..
drwxr-xr-x   2 root root 4096 2004-09-24 12:39 subsys

A fresh "sarge"
# ls -al /var/lock
drwxrwxrwt   4 root root 1024 2005-04-18 23:14 .
drwxr-xr-x  14 root root 1024 2005-04-15 11:15 ..
drwxr-xr-x   2 root root 1024 2005-04-18 23:14 bastille
drwx------   2 root root 1024 2005-03-11 21:11 lvm

So far your are right:
The problem is hidden by the sticky bit.
And so you run into the same problems as with "/tmp".

>> You must create a directory "logcheck" under /var/lock/
>>
>> mkdir /var/lock/logcheck
>> chown logcheck:logcheck /var/lock/logcheck
>> chmod 755 /var/lock/logcheck

>todd 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??

Because it is a "lockfile" and nothing really to be kept secret?
Assume i have an automated powerdown running as user "powerdown"
That should not turn power off while logcheck is running.
So it looks into /var/lock to see what's on.

OTH:
What happens, if a (bad) programm stroes
a lock into /var/lock that (un)intentionally has
the same name as an other program will be using later?
If "root" is going to create the lock, root will "win"
and maybe kill/remove that lock before the first program
really finished.
The results of the first programs are random!
Sometimes locking will simply not work and no one will know
why (because no one will imediately realize, that there is
a file name duplication and root removed teh lock, sometimes...)

If the other (non root) program tries to make the lock, if will
find the lock file, maybe it thinks it is stalled and tries to
remove it. Due to the sticky bit this will fail. Puh. OK. OK?
So the other program is blocked because of an violation
of the first program...
I think that is a very "unwanted behavior".
If i want to block my colleages work to get more CPU, 
i simply create a lock with the same name his programm uses, 
while it is not running.
Is that a bug or a feature?

That hole will not exist if i must use a subdirectory.
It's upto the adim to ensure (and it is possible for him)
the no one "reuses" an already existing directory.
And if, the other program will fail immediately, because
it can't create it's lock anmore, because thw directory
now belongs to someone else.

I hope if becomes more clear why it is better to 
created directories owned by teh "non root" lockers,
and it is no good to use the sticky bit feature?

Are there cases where it makes sense that "any other" program 
can block logcheck running?

>> [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.

Yes, i only wnated to see is some read so for ;-)

>but anyway that part is clear.

Ack, i assuemd that.

>> --------------------------------------------------------------
>>
>>
>> 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,

Just take the email address as it is.
It works! (And only as you saw it,  dont't edit it!)

>perhaps you'll read your bug report.

I'll do.
But i was looking only on the logcheck mailing list archive
and there was nothing visible.

The question to define (IMHO) is:

Is it a wanted/intentionally effect, that "other programs" 
can easily inihibit logcheck runnings by setting a blocking
lockfile into "/var/lock" or was teh intention of the lockfile to 
inihibit runing logcheck in multiple instances, because a logcheck run
can be "lengthly".