Jan Friedel wrote: > ... >> and why isn't "lo" actually "login"? >> > > Yes, you can create class called "login", define it in the > audit_class(4), assign appropriate events to that class via > audit_event(4) and go for using it. >
This reminds me of the termcap file, something that dates back to the 1980s in design. While it achieves its goal, it's quite opaque to read, even though it is meant to be editable. >> After looking at audit_control(4), I thought "this could >> be friendlier" and I think that design could be friendlier >> too :) But maybe that's something for a future project... >> >> Looking at the web page, the namespace used by auditd.xml >> seems to imply that it could be possible for the internal >> schema to collide with a plugin. Wouldn't it be better to >> have a dedicated space in the XML schema that was reserved >> for plugins? >> > > Now, maybe, the webpage you are looking at would be helpful. > Hopefully, we are still talking about the [1]. > I think at the time I was looking at the opensolaris.org project web page for audit as I wasn't on SWAN... > Back to your suggestion - it would be great to have such a > section available here. Unfortunatelly, if I understand > correctly the service_bundle(4) and the respective > /usr/share/lib/xml/dtd/service_bundle.dtd.1, such a structure is > not supported according to the dtd. Darren Moffat had similar > suggestion a week back, and I think we agreed on following > structure: > > `svcprop -p plugin-audit_binfile -p plugin-audit_syslog auditd` > > plugin-audit_binfile application > plugin-audit_binfile/dir astring /var/audit > . > . > > plugin-audit_syslog application > plugin-audit_syslog/enabled boolean false > . > . > Ugh. I've since looked at the DTD that gets the blame and I see the problem that you're referring to here and why the above is necessary. So you're saying that auditd needs to walk through the DTD and look for anyting that is named "plugin-*" and start going through the motions to setup a new plugin when it does? Darren
