22 Jun
2009
22 Jun
'09
9:33 p.m.
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:
I think I may be misunderstanding something.
Or I'm just SSSLLLLOOOOWWWW...
You wrote yesterday:
On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano
(nando(a)ccrma.Stanford.EDU) wrote:
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.
> 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? 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. 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