Subject: Re: [linux-audio-dev] [SOURCE] rt monitor to kill runaway RT processes
From: Fernando Pablo Lopez-Lezcano (nando_AT_ccrma.Stanford.EDU)
Date: Mon Sep 02 2002 - 04:19:39 EEST
> >The only thing the sound servers need to be able to handle
> >RT audio are:
> >* one of the RT scheduling methods.
> >* locked memory. (Not protected at the moment - hard limits?)
>
> >This can be archived with a wrapper that drops ALL other priorities
> >before running the real application.
>
> this is, alas, not true. to use RT scheduling, you need either root
> uid or CAP_RESOURCE. if you have CAP_RESOURCE or root uid, you can do
> many, many things (such as write to /dev/kmem) that can lead to a DOS.
I think you need:
- CAP_SYS_NICE for changing into RT_FIFO, but that also:
/* Allow raising priority and setting priority on other (different
UID) processes */
/* Allow use of FIFO and round-robin (realtime) scheduling on own
processes and setting the scheduling algorithm used by another
process. */
so yes, it is dangerous.
- CAP_IPC_LOCK for locking down memory (mlock and mlockall)
CAP_RESOURCE is only needed if you want to program the rtc clock with a
rate higher than 64Hz. And yes, if you grant it then the process can
override any limits in resource usage assigned to it, not just the rtc.
It is very broad in what it can do.
Jackstart (the small program that can start jackd with rt capabilities)
also gets CAP_SETPCAP which enables it to give capabilities (a restricted
set) to other processes.
> the central problem is that there is no way to tell the kernel "this
> thread should get to run whenever it wants, but do nothing else that a
> normal process cannot do", and likewise, "this vm address space can
> lock down up to 128MB of memory". we don't have sufficiently
> granularity to do this
Yes, capabilities are useful but way too broad.
-- Fernando
This archive was generated by hypermail 2b28 : Mon Sep 02 2002 - 04:31:01 EEST