audit_constant.go constants about audit-go HOT 11 CLOSED

@cristiansavaro I don't think that MAX_AUDIT_MESSAGE_LENGTH will be exceeded. As referenced in linux kernel https://github.com/torvalds/linux/blob/master/include/uapi/linux/audit.h#L392 the audit event messages are within the MAX limit. The constant is itself defined here https://fedorahosted.org/audit/browser/trunk/lib/libaudit.h#L383. Can you give us instances where this limit is exceeded ?

from audit-go.

the respective constant as available is on the 8xxx range. Increasing it to 10000 seem to have done the job.

from audit-go.

@cristiansavaro There are previous discussions on the audit mailing list for the maximum user message limit https://www.redhat.com/archives/linux-audit/2013-September/msg00016.html. This is the reason why the audit buffer is limited to 8970.

from audit-go.

If i let it at 8970 i get this error more than 50% of the time :

[root@oel6 audit-go]# go run main.go
2015/01/28 10:40:11 Acknowledged!!
2015/01/28 10:40:11 NLMSG_ERROR Received..
2015/01/28 10:40:11 Audit Not Enabled! Exiting
exit status 1

What else should I do ?

from audit-go.

@cristiansavaro Do you have auditd service running in background ?
If it is running then you should stop it . ( On ubuntu you can do sudo service auditd status followed by sudo service auditd stop).
This is because only one process can read from the audit netlink socket.

from audit-go.

ok stopped audit daemon. same error !

from audit-go.

@cristiansavaro Can you replace your main.go with this file https://gist.github.com/arunk-s/ce6e80467366877b1de9 and tell us the output.

from audit-go.

This is the output now :

[root@oel6 audit-go]# go run main.go
2015/01/29 07:54:34 Acknowledged!!
2015/01/29 07:54:34 NLMSG_ERROR Received..
2015/01/29 07:54:34 Audit Not Enabled! Exiting resource temporarily unavailable
exit status 1

with the audit daemon stopped as instructed above.

from audit-go.

@cristiansavaro Okay so the problem is that the system call syscall.Recvfrom to receive message takes too long and that's why it exits with error(os.EAGAIN). The problem is not in the code itself but the kernel is taking too long to reply. Currently the function to check if Audit is enabled AuditIsEnabled() is non blocking in nature so it returns if there is no data available, which occurs in your case. Either you can run the program repeatedly to get it working or you can replace your libaudit.go with https://gist.github.com/arunk-s/bfcdc1159a4b07b41b02#file-libaudit-go-L293. I've made the function blocking but the changed is not pushed to repo as it will require some tests. We are currently working on that issue.

from audit-go.

@arunk-s I don't quite understand why libaudit-go using MSG_DONTWAIT. The AuditIsEnabled() and DeleteAllRules() would only be run once at the startup for each execution and waiting that bit longer would have little effect. On my VM with single cpu and 1G RAM, it's almost inevitable that the program exits with EAGAIN as a fatal error. Why not using blocking IO with an appropriate timeout? Thanks.

from audit-go.

@t57root , actually you can try with disabling MSG_DONTWAIT option. I've tried the same on my system and cannot see any visible difference although it may be visible on systems with less resources as you suggested.
Regarding the actual reasons for keeping MSG_DONTWAIT is that we are trying to follow the same conventions as the original auditd code. You can see at the following places, auditd is using GET_REPLY_NONBLOCKING for the above functions with ultimately resolves to MSG_DONTWAIT.
https://fedorahosted.org/audit/browser/trunk/lib/libaudit.c#L379
https://fedorahosted.org/audit/browser/trunk/src/delete_all.c#L62
If any issue occurs please create an issue at libaudit-go, as we are doing the actual library development there.

from audit-go.