Re: ITP: realtime -- Realtime Linux Security Module (fwd)
> Daniel Kobras <kobras@debian.org> writes:
>
>> On Thu, Mar 25, 2004 at 06:07:02PM +0100, guenter geiger wrote:
>> > When the module has been installed succesully you should be able to
>> > run jack without jackstart and suid root, just as
>> > jack -R -d alsa
>> >
Guenter, thanks for this work. I'm rather busy today, so I'll be able to
give it a try on Monday.
>> > At the same time, most of the other applications that require
>> > realtime scheduling and memory locking should work. (For users in
>> > the audio group).
>>
>> Sweet. So what's your plan on handling default permissions? Should we
>> require that all users of audio applications be in group audio, or
>> should we rather start shipping timing-sensitive apps SetGID audio?
>> And with Recommends: realtime, obviously.
>
> I recommend putting the user in group `audio', then running the LSM
> with `gid=29'. They're probably in that group anyway to access the
> sound device.
>
I was thinking to add to the demudi-config task package a debconf question
like "In order to let applications get realtime priviliges the users have
to belong to the audio group. Which users should be included in audio
group?". Would it make sense?
Just for the record the demudi-config package is intended to automatically
tune the system for audio work. I'll upload it to Debian as soon as I
become a maintainer.
> Setgid is theoretically better, but GTK has a misguided policy of
> refusing to run if the application is setuid or setgid, causing quite a
> few applications to fail. QT and non-GUI applications (like JACK) work
> fine with setgid, but the user still ends up needing to be a
> member of group `audio'. That works for everything I've tried. And,
> no one on linux-audio-dev has reported any problems with it. There
> seem to be quite a few using it these days.
I've read some messages on linux-audio-dev reporting a not so good latency
performance with 2.6 series, and they end up using a patched 2.4.
Does anybody know whether the stock debian 2.6.4 kernel is suitable for
low-latency work or not? I guess it should be at least patched with the
low-latency patch for 2.6.4 right?
bye,
Free
Reply to: