[EMAIL PROTECTED] writes: > attached is what i have done today.... works, but needs to > be checked by someone who can judge about the sideeffects.
Cool. Thanks, Torben. Doing it with so little code is encouraging, and speaks well for the modularity of the 2.6 kernel. I looked at your code, but am not completely up to speed on kernel security modules yet. It looks like your module essentially duplicates the effect of the 2.4 "capabilities patch". With this loaded, it will be possible to run the existing `jackstart' exactly as we do today on a capabilities- enabled 2.4 kernel. Is that right? That is wonderful. > i am not so sure about them. I'm not sure about the side effects either, but I plan to study the matter carefully. There is a [EMAIL PROTECTED]' mailing list. Maybe we should post there, asking for comments and suggestions. 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 realtime privileges. One way to allow (or prevent) access to realtime privileges for any program is via a sysctl global variable. Of course, loading the kernel extension is a privileged operation, anyway. But, I prefer some positive means of blocking it. (2) Using sysctl, set a group id (like `audio') for which realtime privileges are automatically granted. Then, we could just install realtime apps with `setgid audio'. This seems much better than opening things up to *any* application. And, audio applications would not need root privileges any more. This would be a rather big improvement over the current jackstart/jackd situation. (3) We could also define a default realtime group (gid 0 maybe), since `audio' probably does not exist on many distributions. IIUC, this is originally a Debian idea. I don't know how widely it has been adopted. I like it and think it should become a universal Linux convention, allowing access to the sound card as well as realtime privileges. -- Jack O'Quin Austin, Texas