17 Nov
2003
17 Nov
'03
7:48 p.m.
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 + 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
Not a problem so far (but I don't like to use LD_PRELOAD at all, just a
personal preference).
+ Protects the system from overuse (and lockups) due
to bugs in code.
Very good.
- 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?)
Well, I'd say this is the showstopper. We really need this. "Unlikely"
is not enough. Eventually memory will run out and the wrong page will
fault and we get a click. We have to be able to lock memory......
BUT, I think a userspace daemon that starts at boot time and protects
against lockups (rt_monitor) would be a very good thing to have.
-- Fernando