Subject: Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Mon Nov 17 2003 - 22:20:45 EET
On Monday 17 November 2003 06.17, Fernando Pablo Lopez-Lezcano wrote:
> 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
What about:
d) redefining sched_setscheduler using LD_PRELOAD with running rt_monitor
+ No change in kernel.
+ No change in application code. (Like capabilities - do not check uid,
but it can fake uids too!)
+ Can use whatever kernel provides
+ Only requires the rt_monitor to be started by root - can be done by init
+ Protects the system from overuse (and lockups) due to bugs in code.
- Can not provide mlockall since it has no pid parameter - the monitor
can't do it for another process. (I would say that it is unlikely that pages
used in a tight audio loop would be thrown out - big buffers might...
Add additional page reads?)
/RogerL
-- Roger Larsson Skellefteċ Sweden
This archive was generated by hypermail 2b28 : Mon Nov 17 2003 - 22:20:56 EET