Zenaan Harkness <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > 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.
> > > 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.
> 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 <[EMAIL PROTECTED]> and givertcap.c, written by
Tommi Ilmonen, [EMAIL PROTECTED]
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
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.
> > 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.
> > > 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
