Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Peter Williams]

Jack O'Quin wrote:
> Peter Williams <pwil3058@xxxxxxxxxxxxxx> writes:
>
>
> > Paul Davis wrote:
> >
> > > There are several kernel-side attributes that would make JACK better
> > > from my perspective:
> > > 	* better ways to acquire and release RT scheduling
> >
> > I'm no expert on the topic but it would seem to me that the mechanisms
> > associated with the capable() function are intended to provide a
> > consistent and extensible interface to the control of privileged
> > operations with possible finer grained control than "root 'yes' and
> > everybody else 'no'".  Maybe the way to solve this problem is to
> > modify the interpretation of capable(CAP_SYS_NICE) so that it returns
> > true when invoked by a task setuid to a nominated uid in addition to
> > zero?
>
>
> That is essentially what the RT-LSM does.  At exec() time RT-LSM turns
> on CAP_SYS_NICE for appropriate process images.
>
> In the current implementation this is only done per-group not
> per-user.  Adding UID as well as GID granularity should be easy.  We
> didn't do it because we didn't really need it.  If there's a use for
> it, I have no objection to adding it.  It could even compatibly be
> added later.

If what you have is adequate I wouldn't suggest changing it.  My use of 
uid in my rant was just to illustrate a general idea.

> Many distributions require users to join group `audio' anyway to gain
> access to the sound card.  We found it convenient to piggy-back on
> that mechanism.
>
> I believe Paul considers this adequate for his requirements.  :-)

Peter
--
Peter Williams                                   pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/