Re: [PATCH] LSPP audit enablement: storing selinux ocontext and scontext

On Thursday 28 July 2005 12:12, Timothy R. Chavez wrote: > Yeah, I'm thinking I should be calling audit_panic() instead. I don't think so. There are many places in the kernel where failed memory alloc results in -ENOMEM. >  Also, I fail silently if the audit_watch_notify() hook is called and it > can not allocate an memory to place on the audit context... the admin has > no control over this. At least with audit_panic they can specify how they > want the system to fail. This is an exceptional condition. I would be very unhappy as an admin if I had to constantly investigate why my machine had panic'd. I would rather the machine stay alive and have the syscall fail. The user can retry and if memory pressure has eased - we'll get the event. > Let's say our system is extremely stressed out and we fail a memory > allocation that's nonfatal... that record is missed but the system is still > running when really the system should probably panic (in a CAPP environment > at least). That's not presently doable with the fs watch code (should I be > "eeking" right now). If the syscall failed due to audit system problem, the auditable event never occurred. They were prevented. They should retry and hopefully the memory situation has changed.

> I suppose in a CAPP environment if a record cannot be generate the system > should be halted, right? Or the action prevented. -Steve -- Linux-audit mailing list Linux-audit(a)redhat.com http://www.redhat.com/mailman/listinfo/linux-audit