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

[Peter Williams <pwil3058@bigpond.net.au>]

Jack O'Quin wrote:
> Peter Williams <pwil3058@bigpond.net.au> 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@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce