* Stephen Smalley (sds@private) wrote: > 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. I assume this is due to wakeup code putting smth. on the runqueue? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 11:27:55 PDT