AuditSetPID fails when auditd is running on the system

[ameihm0912]

When auditd is already running on the system, calls to AuditSetPID will end up failing, and do not provide any indication of what the issue is aside from an errno integer. Not sure if there is a better way to handle this, or perhaps convert the incoming errno value into something more indicative of what the problem is.

[arunk-s]

Ah yeah, I think if auditd is already running on the system, the kernel will not accept the libaudit-go client to allow anything to deal with the audit framework (listing rules, adding rules etc. ) , so I think we should add a mandatory check to see if auditd is already running + Add instructions on Readme to warn the users as well. Regarding the errno integer, there are other functions as well https://github.com/mozilla/libaudit-go/blob/master/libaudit.go#L317 where we simply return the integer value. The auditd library uses custom error tables( https://fedorahosted.org/audit/browser/trunk/lib/errtab.h ) and provides a wrapper around them https://fedorahosted.org/audit/browser/trunk/lib/lookup_table.c#L318 audit_errno_to_name which then it uses for interpretation: https://fedorahosted.org/audit/browser/trunk/auparse/interpret.c#L758 -- libaudit-go counterpart (https://github.com/mozilla/libaudit-go/blob/master/interpret.go#L305)

But it also uses sterror function provided by the linux API at places https://fedorahosted.org/audit/browser/trunk/lib/libaudit.c#L444 to convert error codes to strings.

So if we plan to convert the errno value we will need to add generic functions that relies on the underlying strerror function + the custom error tables.