Re: Proposal: New Auditd Design

When log out to remote host we need the remote host to response back status if the log has been written or failed. Network logging must be some kind of transaction. I'd use D-BUS/RPC or XMLRPC for this. I have done some tiny fast encrypted XMLRPC protocol that uses RSA with MAC though I cannot put it public place now, we may be able to use it in the future. Anyway logging to remote host could be very slow comparing to writing to disk. So either way you need to change current code to do more multi threading with buffering to do remote logging because current implementation is serialized I/O, main process which reads netlink socket is blocked until writing to disk completes. I'm not sure how busy the audit events come in from kernel, auditd could drop some packets. So I did plugin with multi threading to minimize the risk of packet drop. However I don't know if people who use auditd want serialized I/O and don't care packet drops if it is too busy to handle. I did plugin support to avoid audit packet drops. My version writes to disk(network) whenever consumer thread(s) get CPU. Thus there some audit logs stay on memory certain time until they are written to disk. Let me know if you did serialized I/O for the purpose that caching log on memory causes some issues for people who use auditd. Thanks -- Junji Kanemaru Linuon Inc. Tokyo Japan