[linux-audio-dev] Re: POSIX caps/realtime/root processes

[Jack O'Quin]

Kjetil Svalastog Matheussen <k.s.matheussen at notam02.no> writes:

> > I did this as a baseline before adding the `realtimegroup' logic we
> >discussed last week.  I think I'll attempt that next, after fixing
> >the SCHED_RR omission.
> 
> I thought about hacking together those additions after it was posted,
> but soon after Robert posted a module that seemed to solve the problem
> in a much better way.  Whats the status of that patch, and does it
> only work with 2.6.
> 
> And in case it only works with 2.6, can't a similar module be made for
> 2.4? I know it can, because we can just copy the code in the
> sys_setched and sys_mlockall functions into the module.

The Linux Security Module (LSM) interface is a standard part of 2.6.
There actually is a backport of the security modules patch to 2.4 on
the NSA site for SELinux.  But, it is quite large and I doubt many
people would want to apply it for running realtime audio.  Your small
patch is probably safer and more secure.

So, my feeling is that the best approach is...

  (1) LSM for 2.6.  

  This is something we might ask multimedia distributions to
  distribute, enabling an optional turn-key solution for realtime
  audio.

  (2) An interface-compatible variant of your patch for 2.4.  

  This would probably only be available for do-it-yourself kernel
  builders and via special-purpose distributions like Planet CCRMA.
  Basically, this is for people who are currently using capabilities
  and need to continue using 2.4 for a while.  I don't see it as a
  long-term solution.  Most of those people will probably migrate to
  2.6 fairly quickly.

Some applications may want to test whether the `kernel/realtime*'
variables exist.  At least they would work the same, when present.
Generally, the best way for an application to test their privileges is
by directly trying the desired system call to see if it works or
returns EPERM.  In the face of capabilities patches, your patch,
optional LSM features, and users running as `root', this is the only
reasonable thing to do.  Some programs test for (geteuid() == 0),
which was already a mistake.

I intend to continue experimenting along these lines until I prove to
myself that all this really works and is useful.  So, far it looks
encouraging.

Regards,
-- 
  joq