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

[Fernando Pablo Lopez-Lezcano]

On Mon, 2003-11-17 at 08:17, Jack O'Quin wrote:
> 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 say that for 2.4 a simple patch would be easier. I'm a bit tired
of hard to (re)apply kernel patches :-)

> > 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.

I agree, sounds better. It does not say what it does as the original
proposal, but maybe we will need something else in the future that could
be done through this as well. 

> >   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.  

Maybe "realtimegroup"? I kind of like the same "root" for both options,
it groups them together. 

> 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).

Yes, probably "nogroup" is the best option. I think it is "nobody" in my
system - so we cannot rely on the same name either... yuck...

> 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 hope so.......
Looks good to me. 
-- Fernando