On Mon, 2009-06-22 at 14:18 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2009-06-22 at 22:04 +0200, Lennart Poettering wrote:
> > On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano (nando@email-addr-hidden) 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:
> 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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 04:15:06 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 04:15:06 EEST