- User Since
- May 9 2014, 11:04 PM (218 w, 2 d)
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?
Sat, Jul 14
Fri, Jul 13
Wed, Jul 11
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
Tue, Jul 10
@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.
Fri, Jul 6
Thu, Jul 5
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.
Wed, Jul 4
The failure test case looks ok, but I think we should wait for the success test case before committing.
Tue, Jul 3
How about audit(2)?
Mon, Jul 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.
Sun, Jul 1
Fri, Jun 29
Wed, Jun 27
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.
Tue, Jun 26
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).
Mon, Jun 25
Sat, Jun 23
Fri, Jun 22
Do these complete the IPC set?
Thu, Jun 21
Wed, Jun 20
Don't forget the _WANT_SEMUN change.
Tue, Jun 19
LGTM. sendmsg(2), by the way, is my least favorite system call of all time.