Query regarding the lib audit-userspace
Steve Grubb
sgrubb at redhat.com
Tue Sep 13 17:25:44 UTC 2022
Hello,
On Tuesday, September 13, 2022 12:53:32 PM EDT Manojkiran Eda wrote:
> I was working on leveraging the libaudit shared library to generate audit
> events from a user space daemon. I have been using the audit_open as well
> as audit_log_acct_message() API’s to send message to the kernel audit
> subsystem.
audit_log_acct_message() is meant to send events related to a user's
account. For example, pam and shadow-utils uses it.
> From the man pages I understand that every message to the
> kernel audit subsystem would get an ACK back.
Yes. This is to let you know if there was a problem such as lack of
permissions.
> Now my question is does the daemon[single threaded] consuming this libaudit
> for sending events using audit_log_acct_message() API be blocked until it
> gets an ACK back from the kernel ?
Yes. In general, sending audit events should be rare.
> If yes , is there a way to not have the application blocked during this
> period ?
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
More information about the Linux-audit
mailing list