Re: Friendlier EPERM - Request for input

[Eric Paris <eparis@redhat.com>]

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.  If userspace calls get_last_audit_record() we
might be able to dump the record to auditd.  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....