[linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
Jack O'Quin
joq at io.com
Mon Nov 17 16:17:45 UTC 2003
Fernando Pablo Lopez-Lezcano <nando at ccrma.stanford.edu> writes:
> As far as I understand these are the current options:
>
> a) capabilities
> b) simple sysctl patch to the kernel (like the one that Kjetil posted)
> c) security module, with possible additional control through sysctl
>
> "b" is better than "a" (more general purpose)
> is "b" riskier than "a"?
> you could say yes: all programs can use realtime caps
> you could say no: "a" enables additional unneeded and dangerous stuff
> "c" is the same as "b" (from the point of view of a user or sysadmin)
> "c" has more long term potential in the sense that it uses a recognized
> kernel interface to security (but only on 2.6, right?)
Right. There actually is a backport of the security modules patch to
2.4 on the NSA site for SELinux. But, it is rather large and I doubt
many people would want to apply it.
> I would be happy with "b" right now. A group would not be important in
> _my_ setup, all my users are "audio users", all users can hang the
> machine (I have too much to do to try to start categorizing users :-)
> I would say (as in Kjetil's patch):
> echo "0">/proc/sys/kernel/setschedandmlock
> --> normal behavior
I suggest picking a clearer name, like /proc/sys/kernel/realtime.
> echo "1">/proc/sys/kernel/setschedandmlock
> --> access to mlock and SCHED_FIFO and:
> echo "xx">/proc/sys/kernel/setschedandmlockgroup
> --> only users in group "xx" can access privileges
> default for "xx" would be "0" which means everybody
Here, I suggest something like /proc/sys/kernel/rtgroup.
Also, 0 is a valid group ID, `root', which might be a reasonable
choice if groups like `audio' and `realtime' are undefined. How about
using -1, instead? Or, maybe `nogroup' (65534 on my system).
So, I'm thinking we could provide these sysctl interfaces on both 2.4
and 2.6, though via different mechanisms...
(1) `kernel/realtime' works as in Kjetil's patch
(2) `kernel/rtgroup' further restricts access
Kjetil's patch could be expanded to include (2), providing consistent
interfaces across kernel versions. Assuming that's agreeable with
him, of course. :-)
I might give it a try myself, just to see if this really works as I
imagine.
--
joq
More information about the Linux-audio-dev
mailing list