On Sun, 2003-11-16 at 08:02, Paul Davis wrote: > >> I've been thinking about ways to use this feature to improve and > >> simplify the current security situation for Linux audio. No > >> conclusions, but here are some thoughts for discussion: > >> > >> (1) There should a simple way for the sysadmin to reliably disallow > [ .. ] > >> (2) Using sysctl, set a group id (like `audio') for which realtime > [ ... ] > >> (3) We could also define a default realtime group (gid 0 maybe), > > >What about this one: > > > >(4) Let the user that is currently physical logged in to the machine > >get realtime privileges. > > i'd be interested to hear from fernando about this kind of thing. many > of us on LAD work on what are to all effects and purposes single user > machines. i'd like to hear how policies like 1-4 above, or others, > appear in the context of an academic "shared resource" environment.
["academic" is probably irrelevant, a commercial studio should see the advantages of the security model if educated] 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?) 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 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 as to (4), it could be useful but I doubt you can easily determine from inside the kernel that a user is "local" (just guessing). > ps. this is the kind of thing that can really distinguish *nix from > other systems. i've heard from at least academic music department > about the problems they've faced since being forced to switch to > windows. I would not want to be in that position... -- Fernando