> > > attached is what i have done today.... works, but needs to > > > be checked by someone who can judge about the sideeffects. > > > > > > i am not so sure about them. > > > > Encouraged by your success, I plan to modify this LSM to implement the > > `kernel/realtime' and `kernel/realtime-group' interfaces we discussed > > recently. I'll keep you posted on how that progresses. > > the most simple way would be parameters given to the module for the > realtime group and user. There are nice macros for module parameters. > > i believe that adding to the currently overridden function > > if( bprm->e_gid == realtime_gid ) { > bprm->cap_effective = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE > bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE > } > > should work fine. > > although i am not happy with CAP_SYS_RESOURCE ( needed for RTC interrupts > 64Hz ) > which also allows a process to Override quota limits.
This was needed to make mlockall work (on 2.4.x). CAP_IPC_LOCK was not enough, I don't know why. We tried removing it and memory locking broke. Is this on 2.6? Maybe it is different. Re: the rtc clock, in 2.4 there is a /proc/sys/dev/rtc/max-user-freq control file that can be used to rise the maximum rtc clock frequency a normal user can set. > But because in drivers/char/rtc.c the check is > if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq } > > it seems like its not possible with the current implementation. > but we could however provide a jackrtc module which checks for a > new CAP_RTC_INTS. -- Fernando