Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Apr 2005 11:39:48 +0900
From:      Joel <rees@ddcom.co.jp>
To:        freebsd-stable@freebsd.org
Subject:   Re: Misleading security message output
Message-ID:  <20050422111943.1987.REES@ddcom.co.jp>
In-Reply-To: <20050421235218.GA76511@gurney.reilly.home>
References:  <20050418103032.9618.REES@ddcom.co.jp> <20050421235218.GA76511@gurney.reilly.home>

next in thread | previous in thread | raw e-mail | index | archive | help
> > The first question that comes to mind: do you really need logs from a
> > year back? 
> 
> Nope.  Should I need to tweak the default config files to ensure
> that I dont get them?

Since that's the element that brings three possible mis-features
together in the unfortunate interaction, and is also the element that
you have the most direct and immediate control over, and also should not
be a difficult fix, I would sure see it as the tempting fix.

I think I'd also want to submit a feature request to whoever is
currently claiming the program that generates the logs.

> > Maybe it's because I'm such a newb, but I'm wondering which program has
> > what bug? Is it that the default configuration files for the login logs
> > doesn't put on age limit on the rotation? Is it that the log lines don't
> > conain a full 4-digit year in the timestamp? Or is it that the
> > logscraper doesn't know to check the age of a log file, or doesn't know
> > to work on the tail of the log?
> 
> The bug is in the security logscraper script, because it
> presented a log entry from a year ago as something that happened
> yesterday. 

The way I see it, that's less where the bug is and more where the bugs
show up.

> The proximate cause of the bug is that the log
> files don't contain a year as part of the date format.  The
> easy work-around is to include timed rotation as part of the
> standard configuration so that the lack of a year in the logfile
> date format does not expose the bug in the script.  There are
> two plausible "real fixes" for the bug: 1) use a backup+diff
> scheme to find "yesterday's log messgaes" -- this is what NetBSD
> does, or 2) change the syslog daemon to include the year in the
> logfile date stamp -- this is what daemontools' multilog does.
> Option 2 is likely to be difficult to roll into the standard
> because it would almost certainly break third-party logfile
> scrapers.

I'm thinking that the logscrapers are likely not to be going to the
trouble of grabbing only two digits out of the year field, but I
probably don't see as much code as you do.

I see I'm preaching to the choir, and that we just have different points
of view about how deep you want to reach into freeBSD to fix your bug.

:)

--
Joel Rees   <rees@ddcom.co.jp>
digitcom, inc.   $B3t<02q<R%G%8%3%`(B
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp>; **



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050422111943.1987.REES>