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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
From: Jack O'Quin (joq_AT_io.com)
Date: Mon Nov 17 2003 - 18:17:45 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Nov 17 2003 - 18:16:57 EET