On Sun, 2003-11-02 at 05:40, Jack O'Quin wrote: > 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.
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 <[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 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
