Re: RFC: realtime LSM

From: Jack O'Quin (joq@private)
Date: Thu Mar 04 2004 - 16:46:12 PST

  • Next message: Serge Hallyn: "New bsdjail.c"

    Chris Wright <chrisw@private> writes:
    > Couple quick questions.  Which kernel version were you working with?
    I've tested it with 2.6.0 and 2.6.3, both vanilla versions from  I know of others who have run it with some of the -mm
    versions, too.  AFAIK, no one has tried it with 2.4.
    > Are your groups tests still valid?  
    As far as I can tell.  Has something changed that I should watch out
    For useability reasons it was important to test the concurrent groups
    list.  Several distributions define a group `audio' which has access
    to the sound hardware.  It works well to use membership in that group
    for granting realtime privileges, too.
    Here are the current group tests...
    	/* check group permissions */
    	if ((gid != -1) &&
    	    (gid != bprm->e_gid) &&
    	    (gid != current->gid)) {
    		int i;
    		rt_ok = 0;
    		for (i = 0; i < NGROUPS; ++i) {
    			if (gid == current->groups[i]) {
    				rt_ok = 1;
    > Is your main goal to be able to mlock() only, or mlock and
    > setscheduler?  
    For realtime audio we generally need both SCHED_FIFO and mlockall().
    BTW, the kernel has a bug (feature?) which causes mlockall() to fail
    with EPERM unless the caller possesses *both* CAP_IPC_LOCK and
    CAP_SYS_RESOURCE.  The latter is unfortunate, because it also grants a
    bunch of unrelated and undesireable privileges.  This is true for both
    2.4 and 2.6.  I have searched the kernel souces several times without
    finding where that second test occurs.  CAP_IPC_LOCK is tested right
    where you would expect it, in `mm/mlock.c'.
    Partly for this reason, and also because it's not always necessary,
    the LSM has an `mlock=0' option, in which case only CAP_SYS_NICE is
    granted.  The scheduler privileges are always necessary.
    > I have a patch which allow users to mlock(), and this would not
    > require any change to the security model of the system.  I grabbed
    > it from a 2.4 RH kernel and forward ported it to 2.6.  I'll post it
    > later this afternoon if you'd like.
    I already have one patch for 2.4 that covers them both.  But, I'd like
    to see yours too.
    The main advantage of the LSM approach is that distributions can
    provide it as a binary extension, so their users don't need to patch
    the kernel.  My current package does not achieve that, since a kernel
    build is still required although without patches.  It certainly does
    not belong in mainstream kernel images.
    The consensus is that 2.4 users can continue to live with patching the
    kernel.  They have to do that anyway to get decent audio performance.

    This archive was generated by hypermail 2b30 : Thu Mar 04 2004 - 16:47:36 PST