fw: jackd/ audio apps mini policy
(Thread was on debian-mentors, now being moved to debian-multimedia for
those interested...)
-----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.
>
> > 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...
>
> Sure.
>
> > Title: Audio Apps Mini Policy
> > Authors: Zenaan Harkness
> > Version: 0.1
> > Date: 2003-10-28
> >
> > Applicability: Audio apps requiring realtime scheduling (or other root)
> > privileges to operate effectively.
> >
> > Policy:
> > Audio applications or applets (ie. executable files) requiring realtime
> > privileges should be installed as follows:
>
> I like the idea of a configurable wrapper for those apps that is
> provided by libjack and used in the case of an unpatched kernel much
> more.
>
> Three cases must be supported:
>
> 1 a) regular (other) user using jackd and all apps without RT caps
> b) root (or user via sudo) using jackd and apps with RT caps
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)?
> 2 audio-user using jackd and apps with a give-RTcap-wrapper and an
> unpatched kernel
> 3 audio-user using jackstart and apps with a give-RTcap patched kernel.
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. ??
> > - user = root
> > - group = audio
> > - permissions
> > - SUID root
> > - have a debconf question asking to allow/ deny this
> > - [debconf question "importance level"??]
>
> rather low.
>
> With a default being defined by another question
> "shared/make-jack-apps-suid-root".
>
> > - user = read, write, execute
> > - group = read, execute
> > - other = read only
> > = 4754 (numeric, octal)
> > = -rwsr-xr-- (symbolic as per "ls -l")
>
> This is strange. It also makes sense for an unprivileged user (other) to
> execute the application (only without RT capabilities). Your
> permissions prohibit that. Denying execution to others is wrong.
I think you're right here ... I was thinking as a user doing
multi-track recording where a single scheduling skip blows
my whole session.
> 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)?
> > For an example of a similar such installation, see the cdrecord binary
> > in the cdrecord package.
> >
> > The debconf question should be along the lines of the following
> > (shamelessly ripped from the cdrecord package):
> > "
> > You have the option of installing [PACKAGENAME] binaries with the SUID
> > bit set.
> >
> > If you make [PACKAGENAME] SUID, you can allow users in the "audio" group
> > to run this software without needing any additional privileges. This
> > could, however, potentially allow [PACKAGENAME] to be used during a
> > security attack on your computer. If in doubt, I suggest you install it
> > without SUID. If you later change your mind, you can run:
> > dpkg-reconfigure [PACKAGENAME].
> >
> > Do you want the [PACKAGENAME] binaries to be installed SUID root?
> > "
> >
> > To be really sexy, such audio packages should ask if there are specific
> > users that should be added to the audio group upon installation. ??
> >
> > Finally, installation of such applications should (should they really?)
> > check for the local machine's administrator's perms/ ownership overrides
> > (specified by dpkg-statoverride) similar to as follows:
> >
> > # allow dpkg-statoverride by local admin to override our permissions
> > if ! dpkg-statoverride --list /usr/bin/jackstart > /dev/null ; then
>
> A more defined conditional is needed here. Being listed doesn't mean
> anything. For this to work jackstart needs to SUID root _and_ the kernel needs
> to be patched.
But if the local admin is using dpkg-statoverride, then they _do_
know what they're doing and will have set these things up properly
... isn't that the assumption wrt statoverrides?
Also, doesn't capabilities (the "patched kernel" I'm guessing),
obviate full root SUID? I'm getting more confused here - but I am
only an admin for my own laptop for about two years now, so still
plenty to learn - more every day it seems :)
> > db_get ....
> > if [ "$RET" = "true" ]; then
> > chmod 4754 .. chown
> > else
> > chmod 0755
> > fi
> > fi
>
> > Anyone, how does Andreas' comment "We _do_ have an audio-group and users
> > who need to have access to /dev/{mixer,snd,dsp,..} should be put in
> > there, instead of making the app SGID." apply here - ie. am I confused
> > about the use of SUID?
>
> As said. device permission != RT capability permission
>
> > Another comment I received, this time about capabilities, was the
> > following (there is the JACK (jackd) audio daemon, and "jackstart"
> > program to run it): "With jackstart. you can run jackd and it's clients
> > as non-root user - only jackstart has to be setuid root, jackd need not.
> > This has the advantage that files recorded with a jack client like
> > ardour aren't owned by root, for example."
> > I could not find information on capabilities in the kernel-2.4.22 docs,
> > can someone tell me if this should be mentioned somehow as part of this
> > audio apps mini-policy?
> http://jackit.sourceforge.net/docs/faq.php#a5
> under "Software"
Thanks.
> Robert.
cheers
zen
Reply to: