administrative:auditon_setcond_success fails for me every time, probably because you haven't yet fixed the problem with unbuffered I/O in au_read_rec. How's that coming?

using AUDITPIPE_FLUSH doesn't work. You should remove that part and fix the bug in utils.c instead.

This looks like a real bug, but your reproduction code is wrong. You're passing as the third argument sizeof(&auditpolicy), which is the size of a pointer to the policy variable, not the size of the policy variable itself. To correctly reproduce this, you'll have to fix the sizeof and use a uint64_t argument instead of an int.

Remove errant newline

Don't duplicate AUDIT_SYSCALL_EXIT in exit1

In D16210#344023, @aniketp wrote:

Other than the (possible?) repetition of AUDIT_SYSCALL_EXIT in kern_exit.c. The issue with exa(1) seems to have gone away. Also, the regression tests for audit of _exit(2) in D16099 don't fail on introducing this change.

@aniketp are there any exit-related audit events that you haven't tested yet? It would be good to check that this change doesn't break them.

In D16151#342780, @nick_princi.pe wrote:

In D16151#342548, @asomers wrote:

This change looks good. But I have a few overall concerns:

• ISO-8601 allows fractional seconds, at least according to Wikipedia. That would improve -C's accuracy and usefulness.

Sure. I have no problem with that. How would you feel if I omit factional seconds if -I is >=1s, though?

This change looks good. But I have a few overall concerns:

• ISO-8601 allows fractional seconds, at least according to Wikipedia. That would improve -C's accuracy and usefulness.
• The existing logic is fairly ugly. It would be great to do a clean up pass. In particular I think all of the PRINTMSGs could be reduced to a few loops, if you define a format string array and an enabled array.
• What happens if a new device arrives or one goes away while gstat -C is running?

I don't know what you did, but somehow you created this review as a bare diff without any context information. Did you upload the raw diff into reviews.freebsd.org or something? If you use the php5-arcanist command line tool instead, the review will include unchanged portions of the file. It's much easier to review that way.

The failure test case looks ok, but I think we should wait for the success test case before committing.

How about audit(2)?

For me cap_enter_success passes intermittently. On a case when it failed, the global audit trail showed the cap_enter call we were looking for (as well as the child's exit(2), which is also in class "pc"). But the auditpipe showed nothing after fork. I think we're looking at a buffering issue. When I run "./process_control cap_enter_success" the last thing I see is the fork record. Then the process pauses for 10 seconds. But while it's paused, if I run any command at all in another terminal, then the test immediately passes. So I think that the auditpipe(4) device is buffering up some amount of data before its read(2) returns.

If you intend to add successful test cases for mount, swapon, etc later, then you shouldn't indicate them as TODOs in the comments. Remove the text about how mount can't be tested in success mode.

This is still incorrect. sizeof(buff) returns 80. That means that extattr_set_file is going to set the attribute's value to ezio\0 followed by 75 bytes of stack garbage. You might try leaving buff's length unspecified, by declaring it like static char buff[] = "ezio";. Whatever you do, ensure that the nbytes argument is either 4 (if you don't desire NULL termination) or 5 (if you do).

Do these complete the IPC set?

Don't forget the _WANT_SEMUN change.

LGTM. sendmsg(2), by the way, is my least favorite system call of all time.

In D15871#335722, @aniketp wrote:

Instead of passing allocated and unitialized memory as the length for {get/set}audit_addr, simply pass the sizeof(auditinfo) as it is supposed to be used.

Thanks to @asomers for suggesting. Although I wish the man-page was a bit more clear on
this regard (about what exactly is length).