[linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Jack O'Quin]

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