On Tue, 2004-10-19 at 08:14, Stephen Smalley wrote: > I think that you need to hold the lock when extracting p->policy, and if > you drop the lock for the security checks, you need to recheck that > p->policy hasn't changed after you re-take the lock. Advantage of your > approach (with those fixes) is that no special handling is required by > capable(CAP_SYS_NICE) and security_task_setscheduler hook > implementations; they can audit immediately. But given that the audit > framework does support deferred auditing via audit_log_end_irq, I'm not > sure that this is going to be compelling upstream, as it makes > setscheduler() very convoluted. Hmmm...may have spoken too soon; looks like audit_log_end_irq can deadlock too when the runqueue lock is held. Only option is to disable auditing of CAP_SYS_NICE and setscheduler? Very unpleasant. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 11:21:08 PDT