[EMAIL PROTECTED] 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
