22 Jun
2009
22 Jun
'09
7:17 p.m.
On Mon, 2009-06-22 at 22:04 +0200, Lennart Poettering wrote:
On Mon, 22.06.09 12:51, Fernando Lopez-Lezcano
(nando(a)ccrma.Stanford.EDU) wrote:
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.
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. 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