Re: fw: jackd/ audio apps mini policy
On Sun, 2003-11-02 at 05:40, Jack O'Quin wrote:
> Zenaan Harkness <zen@iptaustralia.net> writes:
>
> > (Thread was on debian-mentors, now being moved to debian-multimedia for
> > those interested...)
>
> As a JACK upstream developer and Debian user, I am interested in this
> discussion. But, I am unclear about the overall context. So, maybe
> my comments (below) are a little off-topic. If so, please excuse.
>
> > -----Forwarded Message-----
> > > From: Robert Joerdens <robertjo@phys.ethz.ch>
> > > On Mon, 27 Oct 2003, Zenaan Harkness wrote:
> > > > That's it for now. Do you guys think a small policy/ recommendation
> > > > doclet would be useful for audio software packagers - ie. at least for
> > > > those that require realtime scheduling?
> > >
> > > Yes. But I think since this can be off-loaded to jackd, it doesn't need
> > > to become a policy.
>
> JACK is a useful package. But, it does not aspire to become the
> answer to all questions including the words "Linux" and "audio". What
> exactly is being off-loaded here?
>
> These are some very deep kernel design, system security, and
> administration issues. The Linux kernel does not provide the services
> we really need. So, the discussion devolves into engineering
> tradeoffs between unpleasant choices.
For the benefit of those not versed in deep kernel issues wrt audio
apps, and the benefit of documenting this (very briefly) on debian-mm
list, can you please summarize very briefly these issues/ tradeoffs. By
doing so, we can hopefully understand better the requirements wrt
packaging audio software for Debian...
> > > > I really would like to see Debian become easy-as for installing audio
> > > > software. At the moment, it still takes a bit of administration skill to
> > > > set up, it seems...
>
> I really like the use of understatement. :-)
>
> > So from the sound of it, there's no way to get RT scheduling
> > other than running as root, without a suitably-patched kernel
> > (ie., we have to run as full root)?
>
> I know of no way to do realtime audio under Linux as an ordinary user
> without the kernel capabilities patch. Forcing users to apply this
> patch is a major hassle for Linux audio developers. If Debian can
> come up any solution at all, it would be most welcome.
If I understand correctly, Linux 2.6 has capabilities patch included in
mainline, thus eliminating this as a problem. Since it also includes
lowlatency and preemption patches, we can simply have a "task" package
or such that depends on kernel >= 2.6.0 or something.
> > I thought jackstart was essentially equivalent to a generic wrapper
> > - both require RTcap-patched kernel. Which would mean the only
> > difference between 2 and 3 here is the use of jackstart vs. generic
> > wrapper, where jackstart is more intelligent about jack command
> > line args. ??
>
> Actually, jackstart knows nothing about jackd command args. It is a
> minimal trusted program written by Fernando Lopez-Lezcano (of Planet
> CCRMA fame) for invoking jackd with realtime capabilities as carefully
> as possible. From the comments...
>
> Jackstart is based on code and concepts found in sucap.c, written by
> Finn Arne Gangstad <finnag@guardian.no> and givertcap.c, written by
> Tommi Ilmonen, Tommi.Ilmonen@hut.fi
>
> Basically, jackstart checks that it is running as root, that the
> necessary realtime capabilities are available (CAP_SETPCAP,
> CAP_SYS_NICE, CAP_SYS_RESOURCE, and CAP_IPC_LOCK), that the jackd
> binary is not writeable by non-root users and that its md5 checksum
> matches what was built.
>
> So far, no one is sure why CAP_SYS_RESOURCE is needed, but we find
> that mlockall() fails without it. Realtime scheduling without locking
Presumably a good question for linux-kernel mailing list
> memory is basically useless. This privilege is more dangerous than
> CAP_SYS_NICE or CAP_IPC_LOCK, which at worst facilitate local denial
> of service attacks. CAP_SETPCAP is also dangerous, but it is needed
> for jackd to delegate the other privileges to its clients.
>
> At any rate, this is all much safer than running large amounts of
> untrusted audio code as root. The "least privilege principle" of
> system security states that a program should be delegated no more
> privileges than needed to do its job.
And should drop any privileges as soon as no longer needed.
> > > OTOH jackstart needs to be 4754 root.audio, which is sufficient
> > > because others can start jackd.
> >
> > So jackstart is all that's needed to be root (I guess that would
> > have to have been the point of it)?
>
> That's right.
>
> We want to minimize the amount of trusted code. In system security
> jargon, "trust" is a negative word. The "trusted computing base" is
> defined to be all the hardware and software that can undermine the
> system security policy.
>
> Since we cannot assume the universal existence of group `audio', the
> JACK `make install' sets jackd to root.root 0555 and jackstart to
> root.root 04555. This is only done if the install is running as root
> and JACK was built using --enable-capabilities.
On Debian there is an audio group, and so Debian packages should install
using it. Isn't it possible to manually check this though, for
non-Debian "make install"?
> > > > For an example of a similar such installation, see the cdrecord
> > > > binary in the cdrecord package.
>
> This is a good idea, IMHO. The audio group is a useful concept, even
> though not sufficient by itself.
>
> --
> Jack O'Quin
> Austin, Texas
cheers
zen
Reply to: