Hi James, On Thu, Jan 03, 2008 at 09:27:53AM -0500, James Carlson wrote:
> It'd help a bit to have an evaluation in CR 6185615; I'm missing some > background in reading this case. I've moved one of my comments from that section of the CR into the Evaluation as it seemed to pretty much sum up everything I've come up with so far. Please let me know of any holes that need filling. > Why not make auditconfig set the new p_fsize parameter in response to > the -setfsize keyword, or alternatively have audit_binfile read the > parameter on start-up from some common location into which -setfsize > writes? I assume there's some sort of timing problem involved, but > I'm not sure what it is. I believe that would be possible, and I do not think at first glance that there's a technical argument for not implementing it that way. However, it could be said that the alternative of removing the interface is more in line with the direction that the auditing tools seem to be heading. As I understand it, when auditconfig's '-setfsize' parameter was originally conceived, writing to files on disk was the only auditing method. Now that the actual writing of the data has been abstracted and assigned to multiple plugins, there are theoretically many different backends that could be used to actually write the data (for example the audit_syslog(5) plugin will send the data to syslog instead of writing directly to a file). As such, the concept of a filesize (or even a file) does not necessarily apply to all current and future plugins so it seems reasonable to remove this from the more general auditconfig command and into the individual plugins that need it (and passing keywords via the plugin entries in the audit_control(4) file is the existing method for configuring plugin behavior). If the responsibility remained within auditconfig, depending on the implementation chosen, it may need to know which plugins could use the maximum filesize (in the future there could conceivably be other file-based plugins) and which couldn't. This seems like it could create either too tight a coupling between the auditconfig command and the plugins themselves, or else result in a special method for configuring the audit_binfile(5) plugin which differed from the other plugins (theoretical future plugins that is). Regards, - Paul
