I'm a little behind with my email. Just read this. I find editing kernel hearder quite a hardcore solution to not running as root. Are there any OS X Core Audio developers on this list who know how Apple does it? Appearently all apps that need to run in realtime regardless of the user. -lee On Fri, 27 Feb 2004, Florian Schmidt wrote:

On 6 Mar 2004, Jack O'Quin wrote: [...] Btw, I just tried this for the first time, and I must say it is pretty excellent - small, does the job and is easy to install (assuming you are using a 2.6 kernel)! Even better would be if we managed to get this into the kernel tree. There seems to be a few simple LSM modules already included, so I guess it's not impossible. PS One feature request: some way to turn the realtime mode off. As 2.6 doesn't allow to remove modules, there's currently no way to disable and/or change realtime mode settings. -- http://www.eca.cx Audio software for Linux!

Florian Schmidt <mista.tapas(a)gmx.net> writes: Unfortunately, the default for that kernel config option is "no", so you have to enable it explicitly. I plan to add an interface to set or query the state of the LSM using the /proc filesystem. Then, you will be able to disable it even if the kernel is not configured for module unloading. -- joq

On Saturday 28 February 2004 10:25, Hasse Hagen Johansen wrote: If you are using gentoo (you told so) there already is a audio group. Members of this group are the ones who access the sounddevices... Arnold -- Get my public-key from pgp.mit.edu or pgp.uni-mainz.de --- Hi, I am a .signature virus. Please copy me into your ~/.signature and send me to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your administrator to do so...

Arnold> Apart from other "official" solutions I did set the suid Arnold> flag on all the binaries I need and changed the group to Arnold> audio (and let others not execute the bins)... Arnold> That way I can have excellent latency times while still Arnold> being my normal user. Jack> Maybe the easiest, but probably also the least secure. Yes. I know :-) Jack> setuid. Then at least, the person running untrusted code Jack> with super-powers has to know the root password. His Jack> judgement may be in question, but his authority is not. :-) Jack> The `audio' group is a good idea, and has standard support Jack> in both Gentoo and Debian. I'm not sure about other Jack> distributions, but it is easy to add this group yourself if Jack> it's not already defined. Jack> Sadly, Linux development remains quite disorganized when it Jack> comes to realtime privileges. I wish there were a simple Jack> answer to your question. Jack> My feeling is that the best available approach is granting Jack> realtime privileges based on membership in this group. With Jack> 2.4 kernels that requires a kernel patch. Several have been Jack> posted in the past, but AFAIK none are actively maintained. Jack> For 2.6 kernels, there is a dynamically-installable Linux Jack> Security Module[1] originally written by Torben Hohn, later Jack> modified and packaged by me. Although still experimental, I Jack> support it and intend to make it an official project. It Jack> does not require any kernel patches, but you do need kernel Jack> sources to build it. This LSM grants realtime privileges Jack> based on several user-controlled options[2]. Jack> [1] http://www.joq.us/realtime [2] Jack> http://www.joq.us/realtime/README Jack> The option I recommend and use is `gid=29', which grants Jack> realtime privileges to any process belonging to the Debian Jack> `audio' group. Adding a user ID to this group grants access Jack> to both the audio device and to the necessary realtime Jack> privileges. -- joq Hmm. There is some discussion if the LSM is actually very secure. That why RSBAC is not using/is implemented as an LSM, but of course there is always discussions... and I cannot use 2.6.x kernels right now because fo some promise raid drivers (Yeahh that was the wrong choice should have used linux md instead) I was actualy thinking about if I could use EA/ACL and/or rsbac or grsecurity, for granting specific users running specific executables the Realtime capability /Hasse

Jack> All the complaints I've seen about LSM were rather vague, Jack> and mostly seem motivated by discontent that someone else's Jack> security hooks got introduced into the mainline kernel. The Jack> current hooks are quite adequate for my simple needs. Jack> Do you know of any specific security problems that I should Jack> watch out for? None have been mentioned on the Jack> linux-security-module mailing list. I don't know about any security bugs for LSM. I haven't even tried it. (As I mentioned I cannot upgrade to 2.6 kernel at the moment) But I don't think the arguments a vague...http://rsbac.org/lsm.htm Jack> That would be nice. How would you propose to go about it? Jack> To have any traction as a general solution for Linux Audio, Jack> a solution needs to be based on generally-available code. Jack> There is no point in telling users or distibutions: "apply Jack> this 30,000-line patch to your kernel, then tag the Jack> following 127 files with Access Control Lists." It won't Jack> happen. -- joq I agree about that it should be easy, or else it will not be used, but you have to use some kind of ACL's to grant specific Capabilities to specific executables depeding on which user runs the executable. Sorry about starting this discussion. I was only interested how people used jack being nonroot. I just thought that someone maybe used rsbac,grsecurity, or selinux to do this. /Hasse