[linux-audio-dev] Re: [linux-audio-user] jack and setuid

From: Jonathan Woithe <jwoithe@email-addr-hidden>
Date: Fri Nov 04 2005 - 00:49:59 EET

Florian Schmidt wrote:

> > since i'm using 2.6.14 , you mean set_rtlimits from
> > http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz ?
> >
> > but if i run jack as a user, there are no capture ports, and i have tons of
> > xruns.
>
> Just for completeness sake: You can use the realtime lsm for 2.6.13 and
> above, too. I would even recommend it, since it's much less of a hassle
> to setup (rt_limits being the "correct" solution or not).

I'm a bit puzzled by this statement. lsm requires you get the patch, apply
it to your kernel, configure and compile your kernel, install and boot the
new kernel and then you can start configuring userspace to take advantage of
it.

In contrast, using the rtlimits approach can be as simple as grabbing
set_rtlimits and compiling it (assuming one has a kernel >= 2.6.13 installed
of course). Configuring userspace is via a single simple text file
(documented in the source distribution). Using it then boils down to doing
things like

  set_rtlimits -r /usr/local/bin/jackd ...
  set_rtlimits -r /usr/local/bin/ardour

etc when starting applications which need it. Aliases can even be used
to hide the set_rtlimits bit if desired. To me this seems a *lot*
easier than messing around with patched kernels.

It *is* true that (on systems which use PAM) PAM can be patched to provide
access to the rtlimits functionality in a transparent way. I will admit
that doing things this way is complex and a hassle. I wrote set_rtlimits
for two reasons:

 1) give myself access to the rtlimits functionality - my system doesn't
    run PAM, so the PAM patches aren't useful to me personally.

 2) provide a much simpler way to get access to the rtlimits functionality
    in this interim period until PAM (or login in the case of systems not
    using PAM) support rtlimits out the box.

set_rtlimits can also control access to the rtlimit resource on a
per-program basis. A patched login wouldn't be able to do this; PAM may
or may not - I don't know enough about it to comment.

Of course everyone is free to choose the solution which best suits them;
if people prefer lsm that's fine by me.

As a side comment, I'm currently finalising a new version of set_rtlimits.
I've generalised it so it can set other resource limits too -
locked-in-memory size for example - since this can also be useful to control
on a per-program basis. Consequently its name will change to set_rlimits
but the version number will be sequential. Invocation has also been made
easier (absolute paths will no longer need to be specified - they will be
pulled from the configuration file). I expect to have time to finalise it
in the next couple of weeks.

Best regards
  jonathan
Received on Fri Nov 4 04:15:04 2005

This archive was generated by hypermail 2.1.8 : Fri Nov 04 2005 - 04:15:04 EET