17 Nov
2003
17 Nov
'03
7:44 p.m.
On Mon, 2003-11-17 at 08:17, Jack O'Quin wrote:
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.
Maybe "realtimegroup"? I kind of like the same "root" for both
options,
it groups them together.
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. 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).
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