Description of problem: If there are several files in directory /etc/audisp/plugins.d/ with name that can be divided into prefix matching expected configuration file and suffix matching *, audispd will activate the plugin several times. For example if you back up your configuration file (or rpm does for you when installing new pkg version) and the plugin is activated in that conf file, it will be activated even if it is not activated in the "default" configuration file. Version-Release number of selected component (if applicable): # rpm -q audispd-plugins audit audispd-plugins-1.7.7-6.el5 audit-1.7.7-6.el5 How reproducible: always Steps to Reproduce: Here is an example with au-remote.conf: 1. set option 'active = yes' # vim /etc/audisp/plugins.d/au-remote.conf 2. copy the file several times to other files just by adding suffix # cp /etc/audisp/plugins.d/au-remote.conf{,.1} # cp /etc/audisp/plugins.d/au-remote.conf{,.2} 3. set option 'active = no' in the default config # vim /etc/audisp/plugins.d/au-remote.conf 4. restart service # /etc/init.d/auditd restart Stopping auditd: [ OK ] Starting auditd: [ OK ] You will get the same results with /etc/audisp/plugins.d/af_unix.conf. Actual results: 3 plugins are active, while just one should be (af_unix). <snip> Dec 12 06:19:50 nec-em15 kernel: audit(1229080790.681:429): audit_pid=0 old=25887 by auid=0 subj=root:system_r:auditd_t:s0 Dec 12 06:19:50 nec-em15 auditd[25921]: Started dispatcher: /sbin/audispd pid: 25923 Dec 12 06:19:50 nec-em15 audispd: af_unix plugin initialized Dec 12 06:19:50 nec-em15 audispd: audispd initialized with q_depth=80 and 3 active plugins Dec 12 06:19:50 nec-em15 kernel: type=1305 audit(1229080790.800:430): audit_pid=25921 old=0 by auid=0 subj=root:system_r:auditd_t:s0 Dec 12 06:19:50 nec-em15 audisp-remote: audisp-remote is ready for events Dec 12 06:19:50 nec-em15 audisp-remote: audisp-remote is ready for events Dec 12 06:19:50 nec-em15 auditd[25921]: Init complete, auditd 1.7.7 listening for events (startup state enable) </snip> Expected results: Activate just plugins based on the "default" config file, and ignore others matching described pattern.
Fixed in upstream svn commit 206.
audit-1.7.13-1 was built to solve this problem.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: previously, audisp would read not only its configuration file (in /etc/audisp/plugins.d/) but any files with names simlar to its configuration file found in the same directory, for example, backups of the configuration file. As a result, if a plugin were listed in more than one configuration file, it would be activated multiple times. audisp now reads only its configuration file and therefore avoids activating multiple copies of plugins.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,6 +1,5 @@ previously, audisp would read not only its configuration file (in -/etc/audisp/plugins.d/) but any files with names simlar to its configuration +/etc/audisp/plugins.d/) but any files with names similar to its configuration file found in the same directory, for example, backups of the configuration file. As a result, if a plugin were listed in more than one configuration -file, it would be activated multiple times. audisp now reads only its +file, it would be activated multiple times. audisp now filters out any file with a '.' in its name to avoid reading the backup files and therefore avoids activating multiple copies of plugins.-configuration file and therefore avoids activating multiple copies of plugins.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1303.html