Re: cdrecord deadlocks linux 2.6.8.1 (problem in setscheduler)

From: John Johansen (johansen@private)
Date: Wed Oct 20 2004 - 08:49:09 PDT


On Wed, Oct 20, 2004 at 08:23:31AM -0400, Stephen Smalley wrote:
> 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

sigh it seems I posted the wrong patch file the one that got posted is
the one where I threw up my hands and swore about having to break the
lock as Stephan suggests.

The actual patch adds an extra lock (I liked that a little better than
breaking the rq lock) in setscheduler and around the other points that
call __setschedule.

> - 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.
> 

This wouldn't be to bad but I would rather be able to use the 
audit frame work and printk from any lsm hook.

jj



This archive was generated by hypermail 2.1.3 : Wed Oct 20 2004 - 09:02:57 PDT