Description of problem: Logwatch is misparsing userhelper log entries for hddtemp that specify a device using a name that includes a slash. Running '/usr/sbin/hddtemp -n -q /dev/sda' produces in '/var/log/secure' lines like the following: ********** Oct 12 22:35:40 archer userhelper[17819]: running '/usr/sbin/hddtemp -n -q /dev/sda' with root privileges on behalf of 'major' ********** Logwatch reports the following in the 'Connections (secure-log)' section: ********** Userhelper executed applications: major -> sda as root: 1 Time(s) ********** It should be: ********** Userhelper executed applications: major -> hddtemp as root: 1 Time(s) ********** The logwatch script '/usr/share/logwatch/scripts/services/secure' parses the '/var/log/secure' entry using the pattern ********** ($ThisLine =~ /^userhelper\[\d+\]: running '([^']+)' with ([^']+) privileges on behalf of '([^']+)'/) ********** which produces in my example the three strings '/usr/sbin/hddtemp -n -q /dev/sda', 'root', and 'major', later in the script called 'longapp', 'asuser', and 'user' and parsed using the following code: ********** if (keys %Executed_app) { print "\nUserhelper executed applications:\n"; foreach (keys %Executed_app) { ($longapp,$asuser,$user) = split ","; $app = substr($longapp,rindex($longapp,"/")+1); print " $user -> $app as $asuser: ".$Executed_app{"$longapp,$asuser,$user"}." Time(s)\n"; } } ********** The 'longapp' string '/usr/sbin/hddtemp -n -q /dev/sda' is converted to the 'app' string by taking the substring following the last slash, which erroneously gives 'sda'. The 'app' string value should be 'hddtemp', not 'sda'. Version-Release number of selected component (if applicable): logwatch-7.4.0-17.20120619svn110.fc17.noarch How reproducible: Use the command '/usr/sbin/hddtemp -n -q /dev/sda' or some hddtemp command that includes a trailing device name that has a slash in it to produce an entry in '/var/log/secure' and let logwatch analyze it. (The particular hddtemp command that I have been using is actually run as part of a graphical temperature sensor widget.)
Created attachment 629265 [details] [Patch] parse binary correctly
major, could you please try with the attached patch?
(In reply to comment #2) > major, could you please try with the attached patch? To correct a mistake that I made in reporting the error, the command to reproduce the entries in /var/log/secure should be "/usr/bin/hddtemp -n -q /dev/sda" or similar (that's "bin", not "sbin"). After applying and testing the patch, logwatch is correctly parsing the userhelper log entries for hddtemp as the following example shows. ********** Userhelper executed applications: major -> hddtemp as root: 1 Time(s) major -> hddtemp as root: 1 Time(s) major -> hddtemp as root: 1 Time(s) major -> hddtemp as root: 22 Time(s) **********
logwatch-7.4.0-18.20120619svn110.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/logwatch-7.4.0-18.20120619svn110.fc18
logwatch-7.4.0-18.20120619svn110.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/logwatch-7.4.0-18.20120619svn110.fc17
Package logwatch-7.4.0-18.20120619svn110.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing logwatch-7.4.0-18.20120619svn110.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16681/logwatch-7.4.0-18.20120619svn110.fc17 then log in and leave karma (feedback).
logwatch-7.4.0-18.20120619svn110.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.