KDC Audit project
kaduk at MIT.EDU
Tue Jan 8 11:48:05 EST 2013
On Mon, 7 Jan 2013, Dmitri Pal wrote:
> On 01/07/2013 02:25 PM, Zhanna Tsitkov wrote:
>> On Jan 7, 2013, at 2:02 PM, Dmitri Pal wrote:
>>> There should be recognized and known keys like: type of the event
>>> (example KDC start/stop) and may be subtype (start or stop), timestamp,
>>> principal operation is performed with etc.
>>> It will be up to the plugin to decide what to do with the data.
With one-interface-per-event, the plugin knows exactly what it has to do
with the data, there is no room for ambiguity and no need to attempt a
possibly-incorrect "best effort" treatment of unknown data.
>>> Such approach would allow evolving the interface and adding more data to
>>> the events over time without breaking the existing plugins.
>>> Approach listed on the page would make it very hard to evolve the
>>> interface on both sides, we effectively create a "one shot do it right"
>>> which is always hard to accomplish.
The structure of the plugin interface is such that an existing plugin can
continue to do what it originally did, even if new events/interfaces are
added. If a plugin does not supply a handler for an event, it just does
not handle that event.
>>> A generic interface is a bit more work but existing libraries help to
>>> reduce the cost of development.
My sense is that the generic interface would put a heavy burden on the
plugin module author to make an attempt to cover "all possible cases".
Are you saying that it would be more work for us the framework author and
less work for the plugin module author?
>> As a matter of fact we have discussed exactly this approach inside the
>> group. However, it was suggested that too generalized API is not a
>> good idea because of possible confusion while debugging and/or
>> collecting information to be reported. Hence, one-api-per-event
>> We will definitely revisit this topic. Thanks for the comment!
> It depends on the helpers you provide.
> If you use JSON it is easy to print and visualize so it might be the
> best of all approach.
I had the impression that audit tracing was intended to be more structured
than just a simple logfile, so I am not sure that the ease of printing and
visualization is the most relevant feature. If audit records are to be
treated as more of a database to be queried than a static logfile, then
having very structured data is useful. Of course, structured data can be
encoded/serialized in JSON or other ways, but the benefit of serializing
structured data just to decode it again is not clear.
More information about the krbdev