On Tue, 2004-10-19 at 17:09, Chris Wright wrote: > * James Morris (jmorris@private) wrote: > > Yes, it's the runqueue lock. One simple possibility would be to convert > > the audit code over to use the keventd workqueue, and use > > schedule_delayed_work() to kick the audit logging via a timer in this > > case. > > Yeah, guess that would work, but it's not that nice a solution ;-/ And requiring security modules to special case CAP_SYS_NICE auditing in their capable() hooks and any auditing in their setscheduler() hooks seems very unpleasant anyway. I'd actually favor one of: - Fix John's setscheduler patch to hold the lock while extracting p->policy, drop it for the security checks, re-take the lock, and verify that p->policy hasn't changed (if it has, bail with EPERM, as I can't see any legitimate reason for such a race other than an intentional malicious attempt to exploit it), or - Add a separate post hook to setscheduler after locks are dropped, and do all auditing from it. Likely requires changing existing setscheduler hook to return some state to pass along to the post hook for auditing in addition to the error code itself. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Wed Oct 20 2004 - 05:27:44 PDT