Re: Query regarding the lib audit-userspace

Hi Steve, Thanks for the reply. I am actually trying to enable audit events support for an embedded webserver (bmcweb<https://github.com/openbmc/bmcweb>) which implements the DMTF Redfish specification. The idea is to use libaudit to generate server operations related audit events. For example * Authentication related events * Power on related events * Code update related events And the design principle is that all the apps in LF OpenBMC<https://github.com/openbmc/openbmc> are single threaded & use dbus as our communication model & we use event loops for processing events from dbus. I agree that probably it makes sense to disallow a particular operation If we fail to send an event. But can’t we do it without blocking using the event loops ? is there some example of doing that for sending audit events ? As it is a webserver we would want it to as much responsive as possible. And also , how much time does the daemon have to wait for a ACK reply ? does it have a time out of some sort ? I understand that the API that we discussed above does the send as well as receive part, are there specific API’s for just send & receive separately ? so that I could probably add the file descriptor to the event loop and invoke the receive API whenever we get a reply ACK from the kernel. Thank, Manoj From: Steve Grubb <sgrubb(a)redhat.com&gt; Date: Tuesday, 13 September 2022 at 10:55 PM To: linux-audit(a)redhat.com <linux-audit(a)redhat.com&gt; Cc: ManojKiran Eda <manojkiran.eda(a)gmail.com&gt; Subject: Re: Query regarding the lib audit-userspace Hello, On Tuesday, September 13, 2022 12:53:32 PM EDT Manojkiran Eda wrote: audit_log_acct_message() is meant to send events related to a user's account. For example, pam and shadow-utils uses it. Yes. This is to let you know if there was a problem such as lack of permissions. Yes. In general, sending audit events should be rare. The requirements that we normally need to adhere to is that if the audit event fails, then whatever the user was going to do needs to be prevented. If you really need to keep moving, send the event on it's own thread so that your application is not waiting. For example, sshd forks the user session so that it can keep processing other logins. But on that fork, it waits for the responses to make it easier to tear down the session if sending an audit event fails. Or, another approach would be to write the whole thing down to calling sendto and then you can wait however you want. I think putting on it's own thread is simplest. But as I said in the beginning, should there be a problem logging the event, can you undo whatever the event was for if you keep going? -Steve