17 Nov
2003
17 Nov
'03
4:20 p.m.
On Monday 17 November 2003 06.17, Fernando Pablo Lopez-Lezcano wrote:
On Sun, 2003-11-16 at 08:02, Paul Davis wrote:
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
>
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.