On 1/9/2013 1:13 PM, Eric Paris wrote: > On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote: > >> Let me try again, I think I didn't quite get the idea across. >> >> I'm suggesting that the string returned by get_extended_error_info() >> ought to be the audit record the system call would generate, regardless >> of whether the audit system would emit it or not. >> If the audit record doesn't have the information you need we should >> fix the audit system to provide it. Any bit of the information in >> the audit record might be relevant, and your admin or developer might >> need to see it. >> >> I'm suggesting using the audit record because there are tools to >> examine them and it's a pity to use a different format instead of >> fixing the one that's already there. > I get the point. My problem with using audit records is that they have > to be stored on disk, forever. We have to store a record on disk for > EVERY denial because of rwx bits, acls, capabilities, LSM, etc. We > don't do that today and I'm scared of disk growth explosion. Then we > could have a kernel interface, say get_last_audit_record(), which could > query the audit system for that record number. > > A thought on disk size explosion might be something like generating > these records in the kernel and just store them in the task struct until > some later point in time.
Yes! This is exactly what I'm suggesting. > If userspace calls get_last_audit_record() we > might be able to dump the record to auditd. No! Have reading /proc/self/whatwentwrong return the audit record associated with the errno last set by the kernel. > If another record comes > along we have to free the last one and replace it. Lot more of a perf > hit than setting a couple of ints and taking the hit at the time when > userspace actually wants to collect/use this information. > > But are we just building up a rube goldburg machine? I don't see a > problem storing the last audit record if it exists, but I don't like > making audit part of the normal workflow. I'd do it if others like that > though.... > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/