Fernando Lopez-Lezcano:
>
> On Fri, 2007-01-12 at 19:01 -0500, lanas wrote:
>> 3) Adjusted access to priorities by adding this
>> to /etc/security/limits.conf:
>>
>> # Added for audio
>> * - rtprio 99
>> * - nice -10
>> * - memlock 4000000
>>
>> BTW, I read that the above is an insecure configuration. So, some
>> finetuning could be done with that. There's an active Fedora
>> Firewall, as well as SELinux, so maybe this is not as critical as it
>> sounds. I'd appreciate any input on this.
>
> It all boils down to who can use programs that run with realtime
> priorities and whether you trust them. The above conf (which I use)
> gives access to everybody - meaning anybody can potentially hang the
> machine, either through buggy software, a mistake or intentionally.
>
> You can of course restrict things a bit more by using unix groups and
> only give access to a group of users (which you presumably trust...),
> then that's more "secure". Still, allowed users can hang the machine if
> they want.
>
> You could also restrict the range of priorities users can use, add a
> watchdog program that runs at a higer priority and kills or downgrades
> the scheduler to SCHED_OTHER of processes that are hogging the cpu - but
> IMHO things get complicated too fast, and sometimes you may _want_ to
> hog the cpu :-)
>
Except for that want-to-hog-the-cpu scenario (which is very uncommon at
least for audio usage), I would say that using either rt_watchdog or
(especially) das_watchdog is a very good solution to the above mentioned
problems. I don't know whats getting so complicated...
Received on Sat Jan 13 16:15:02 2007
This archive was generated by hypermail 2.1.8 : Sat Jan 13 2007 - 16:15:02 EET