linuxaudio.org

On Mon, 2009-06-22 at 14:18 -0700, Fernando Lopez-Lezcano wrote:

quoted text
> On Mon, 2009-06-22 at 22:04 +0200, Lennart Poettering wrote:

> > On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (nando@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.

>

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

I think I may be misunderstanding something.

Or I'm just SSSLLLLOOOOWWWW... 
You wrote yesterday:

quoted text
> rtkit only comes into play as last resort when rt is cannot otherwise

> be required (at least if developers follow my recommendations from the

> README). If the supervised realtime sched that rtkit gives you isn't

> good enough, then simply give your application unsupervised RT by

> means of RLIMIT_RTPRIO or CAP_SYS_NICE or something suchlike.

If rtkit would demote all processes when triggered, regardless of whether

rtkit granted the privileges or not then I can't really bypass it, it is

always there defining policy. 
-- Fernando
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev