Re: Handling disk full & No Kernel resources
On Wed, 2005-01-05 at 10:09, Mounir Bsaibes wrote:
1) For handling disk full:
Instead of calling the audit_suspend from audit_log_start. I will call
it from audit_syscall_entry
if the context is auditable. audit_suspend will place the process in a
wait_queue until the disk_full_flag is reset. At that time all the
processes in the wait queue will be awakened.
IIUC, almost all tasks are considered auditable at this point, unless
explicitly marked non-auditable via a filter. Hence, this logic will
put almost all tasks to sleep in this scenario. Only tasks that are
explicitly marked as not requiring any auditing will avoid this.
Hopefully this is acceptable and I can go ahead and implement this.
The question is how SELinux should treat its audit records in this
case? For the current CAPP work this is not an issue. However, it will
be for LSPP evaluation.
If any task can reach a SELinux hook (i.e. is not put to sleep on
syscall entry by the above), then the SELinux hook might still trigger
an audit message unless explicitly disabled via policy for that process'
domain (and the relevant object type, class, and permission).
2) For suspending the process whenever there are no kernel
resources:
Audit_log_lost is called from many places for many reasons no
memory, socket is busy, etc.. I need to think a little bit more about
this. If we don't want to sleep in any audit_log* function. Any
suggestion?
I think we need a separate interface for callers that can sleep.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency