[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Mon Jun 22 21:18:19 UTC 2009

On Mon, 2009-06-22 at 22:04 +0200, Lennart Poettering wrote:
> On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (nando at ccrma.Stanford.EDU) wrote:
> > > > Good question. 
> > > > 
> > > > Why is it resetting all the default, even processes with rt privileges
> > > > not granted by RealtimeKit? Isn't rtkit supposed to be the only
> > > > authorized way to access schedulers other that SCHED_OTHER by non-root
> > > > users?
> > > 
> > > rtkit doesn't need to be the exclusive consumer of the kernel RT
> > > interfaces. RLIMIT_RTPRIO is another supported mechanism that
> > > continues to work.
> > 
> > Maybe I did not frame the question correctly: if the system has been
> > configured on purpose by the administrator to grant !SCHED_OTHER by
> > using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
> > did not grant privileges to? 
> rtkit is bus activated. It's only active when it is used. The
> distinction between demoting all and demoting only the 'known'
> processes is hence mostly theoretical.

No, it is absolutely practical. 

> I picked "demoting all" as the default since it 'felt' more
> secure. Dunno. 

Well, sorry but IMO "feeling" has nothing to do with security (I
understand what you are saying, but we cannot base policy decisions like
this one on feeling or beauty or other subjective qualities). 

What is rtkit assuming with that behavior? That any non-root process
that it did not authorize is fair game for it to meddle with. That is an
incorrect assumption. 

> If someone can offer me real-world case where this
> distinction really matters, I am all ears. Otherwise I'd got for the
> safe default for now.

_One_ of the available mechanisms for granting !SCHED_OTHER thinks it is
the only mechanism and acts accordingly. That is wrong. 

-- Fernando

More information about the Linux-audio-dev mailing list