torbenh(a)gmx.de writes:
On Tue, Dec 02, 2003 at 11:03:29AM -0600, Jack
O'Quin wrote:
That's pretty much what I have in mind.
I'm still trying to figure
out how to pass the group id as a parameter somewhere. I wanted to
use /proc/sys/kernel/realtime-group, but that seems to require
patching the kernel. It looks like the new sysfs is intended for this
purpose. I'll investigate.
there are functions to register inodes in proc.
but i dont consider this necessary. Why would i want to change the
realtime gid once the module is loaded ?
modprobe jackcapabilities rtgid=407
seems sufficient to me...
and this requires 2 lines of code... see attachement..
Thanks. I figured there was a way to do that, but had not yet
discovered how.
The desire for a /proc interface was mainly driven by a desire to make
an interface that would be user-space compatible between 2.4 and 2.6,
without requiring 2.4 users to apply that massive selinux patch to
enable LSM support on 2.4. Maybe there's another solution. It
probably doesn't *have* to be compatible. I'll be happy to just get
something that works.
One thing that does seem important is having a really simple way to
shut down the whole mechanism. Unloading the LSM works, but is
probably not convenient for a server system admin looking to quickly
audit all his systems to make sure they don't have these realtime
capabilities enabled. Checking that kernel/realtime is 0 seems good
from this perspective.
considering the configurability of the max frequency
fernando posted,
we need to investigate on mlockall now...
Right. I still have not seen any code in mlockall() that actually
checks CAP_SYS_RESOURCE. But, he and I both tried running jackstart
without it an found that mlockall() failed (with EPERM, IIRC).
Can you add a
new capability without patching the kernel?
definitely yes...
capable can be overridden in an LSM.
but we can still use the current implementation, because capable( i )
tests if bit i is set in the effective_caps.
the highest capability number is 28.. so we have 3 caps left.
Ouch! We'll run out of those in a hurry. :-)
--
joq