This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Friendlier EPERM - Request for input
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....
>
>