[Slackbuilds-users] realtime capabilities for jack and its apps

David Woodfall dave at dawoodfall.net
Mon Aug 22 00:30:42 UTC 2011


On (05:51 21/08/11), B Watson <yalhcru at gmail.com> put forth the proposition:
>On 8/20/11, Felix Pfeifer <pfeifer.felix at googlemail.com> wrote:
>
>> $ whatever.Slackbuild --disable-caps
>>
>> The default behavior then would be to include setcaps in the doinst.sh.
>
>2 things there: it should be an environment variable, e.g. 'export
>CAPS=no' (so it'll work like any other options, and so sbopkg won't
>need to be modified)... and this is a doinst.sh thing, meaning that
>the SlackBuild script would have to edit its own doinst.sh (probably
>with sed), based on the option... Which is not a bad thing, but it's
>definitely more work and more complexity.

It was mentioned to me and the other guys working on the Studioware
project to do this and I will be adding it to our jack and
jack-audio-connection-kit slackbuilds soon, with an appropriate test
for -x /sbin/setcap etc. but only for those applications. I don't
really see the point of adding it to other audio apps if when jack is
installed setcaps is run. It may be that qjackctrl needs realtime too
but I haven't had time to test this yet.

>If it were up to me, I'd just put the setcaps stuff in doinst.sh, not
>make it optional, but I would make a note in the README... and maybe
>I'd install the setcap'ed binaries 0750, owner root, group audio (so
>only users in the audio group can execute them).
>
>So in the SlackBuild itself, you'd have (after 'make install'), something
>like this:
>
>	chmod 0750 $PKG/usr/bin/$PRGNAM
>	chown root.audio $PKG/usr/bin/$PRGNAM
>
>(Add extra lines if there are extra binaries of course).
>
>In doinst.sh:
>
>	setcap cap_ipc_lock,cap_sys_nice=ep usr/bin/whatever
>
>(Again, extra lines if there are extra binaries. setcap doesn't take
>multiple filenames, so you can't say usr/bin/* here. Also notice the
>lack of a leading / [it's usr/bin, not /usr/bin]).
>
>In README:
>
>	Note: This package installs binaries that execute with elevated resource
>	limits. Only users in the audio group will be allowed to run them. [Insert
>	URL of a longer explanation here, maybe].
>
>That's my 2 cents worth (which is probably only worth $0.0002 due to
>inflation).
>
>What say ye, O List?

I can see making jackd audio group only would be a safer option, but
aren't most users in the audio group anyway?

I'll watch this thread with interest anyway.

David

>_______________________________________________
>SlackBuilds-users mailing list
>SlackBuilds-users at slackbuilds.org
>http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - http://slackbuilds.org/faq/

-- 
Don't look back, the lemmings are gaining on you.


More information about the SlackBuilds-users mailing list