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
kernel.org. 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?
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;
break;
}
}
}
> 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.
Thanks,
--
joq
This archive was generated by hypermail 2b30 : Thu Mar 04 2004 - 16:47:36 PST