[linux-audio-dev] new realtime scheduling policy

[Takashi Iwai]

At Tue, 18 Mar 2003 12:23:55 -0500,
Paul Davis wrote:
> 
> >Anyway, I think this patch has its place on linux-kernel. It will most likely 
> >be rejected but it shows that people are interested in these issues...
> >(Who knows Ingo might get another bright idea... :-)
> 
> i agree, but i also raise another angle that i spoke about a couple of
> times at zkm this last weekend.
> 
> using SCHED_(USER)?FIFO makes no sense if you do not also call
> mlockall(2). both (scheduling+memory pinning) are inaccessible without
> root or CAP_SYS_RESOURCE capabilities. i think that a very useful
> patch would be one that used /proc/sys/kernel/rtperm (or some similar
> name) to turn on or off the ability of regular processes to acquire
> these "resources". this would then allow us to use SCHED_FIFO,
> mlockall(2) and any future SCHED_.+FIFO policies without the absurd
> hoops that many people have to jump through at the moment.

i don't think this type of "permit-all-user-and-app" way will be
integrated into the standard kernel.  i mean, it's quite difficult to
convince paranoiac "security guys".  this theme is a bit different
from the scheduler changes. 

i've thought of an implementation of resource-management wrapper
library using a setuid-root helper binary.  the syscalls are replaced
with the wrapper library functions which invoke the helper checking
the access-file wrt
- the caller user/group/hostname
- the caller process exec path
- optionally, the MD5 sum of the binary, or some secret key
and then give the capabilities to the caller process in return.
after changing resources (setsched, mlock), the wrapper reduces the
capabilities again, and go back to the normal operation.
this is somewhat like jackstart does, but in more generic way.
only the helper binary needs setuid-root.  you can restrict the
permissions as you like, per user and/or per application.


btw, regarding capabilities: we have already a proc file,
/proc/sys/kernel/cap-bound.  unfortunately, this proc is used only to
reduce the capability bits and only init process can set the bits,
i.e. totally irreversible.  but, after finding this proc file, i feel
that giving the full capabilities as default in kernel won't be risky
because you can reduce the cap bits in init scripts at any time.


Takashi