Bug 120790

SU failures, bad logins, etc get logged to /var/log/auth.log without a year in the timestamp.  The default /etc/newsyslog.conf only rotates auth.log when it grows over 100k.  On a FreeBSD install with few security events (perhaps caused by infrequent logins such as a firewall/router system or an embedded OS), auth.log may not have been rotated in over a year.  If this happens, and there were security events on todays date a year ago, /etc/periodic/security/800.loginfail will report them again.  This can be confusing at least, and alarming at worst, because these events didn't really happen when they appear to have and may represent users who have been removed from the system, or login events from IP addresses that no longer have access to the system.

Example:  (in this case, note that the system had been renamed since the log event, but that isn't always true)

jules2 login failures:
Feb 17 15:38:57 vincent2 su: BAD SU mcdouga9 to root on /dev/ttyp0
Feb 17 18:25:55 vincent2 su: BAD SU mcdouga9 to root on /dev/ttyp1

Fix: 

A couple things come to mind.  

- Ideally, 800.loginfail should not re-report anything, but it needs enough information to know what is old.  It seems syslogd doesn't record the year in the timestamp of events, so 800.loginfail cannot tell.  Perhaps some modification to the default syslogd and 800.loginfail setup can prevent this.

- Alternatively, reconfigure newsyslog.conf so auth.log is rotated at least once per year.  What I chose to do locally was make auth.log rotate daily and keep 30 days worth.
How-To-Repeat: Cause some SU failures or other events that 800.loginfail reports, then wait a year without causing /var/log/auth.log to be rotated