Filesystem Capability Bits

In the old days, programs that needed to run with elevated privileges had
to be installed setuid root. Since root is the administrator account,
this meant granting all privileges to a program that might only need a
small subset of them.

In modern Linux kernels, it's possible to grant only a small subset of
root-like privileges, such as the ability to lock memory (so it can't be
swapped out) or the ability to bypass file permissions, without granting
*all* of root's privileges. The mechanism for doing this is called
"capabilities", and is documented in the capabilities(7) man page. More
information is available at http://www.friedhoff.org/posixfilecaps.html.
The name "filesystem capability bits" refers to the fact that the
executable files (e.g. /usr/bin/appname) have a set of capability bits
(similar to the permission bits) that can be enabled or disabled (see
setcap(8) and getcap(8)).

If you're reading this, you're probably about to build/install an
audio package that uses jack-audio-connection-kit. These builds by
default enable the "cap_ipc_lock" and "cap_sys_nice" capabilities
on the package's executable(s), when the package is installed (see
capabilities(7) for details).

JACK and its audio applications require these capabilities because they
must service interrupts from the sound device as quickly as possible, in
real time. cap_sys_nice allows the JACK server and its clients to schedule
themselves with realtime priority, and cap_ipc_lock allows them to prevent
themselves from being swapped to disk. Without these capabilities, there
could be audible dropouts ("x-runs", in JACK terminology). Even if you
have lots of really fast cores, it's possible for this to happen due to
normal scheduling latency.

Is it safe to allow applications to use these capabilities? Well, it's
safer than letting them run as root. Badly-behaved programs running
with root access can (deliberately or due to bugs) do anything at all
to your system. The same programs running as a normal user with only
cap_ipc_lock and cap_sys_nice added would be unable to do as much damage.
Generally, the possible damage would be limited to crashing the system,
which would be recoverable by a reboot.

As an extra precaution, the executables with extra capabilities will be
installed with permissions set so they can only be executed by members of
the audio group. You can add yourself to the audio group with usermod(8)
or by editing /etc/group (see group(5)).

If you're sure you don't want to use capability bits, 'export SETCAP=no'
in the SlackBuild script's environment will prevent the package from
including the setcap commands in doinst.sh. Note that this has to be done
at build time (has no effect when installing the package). Without
capabilities, you may experience occasional (or constant) audio dropouts.

If you still get x-runs when using capabilities, there are a few things to
try, in order:

- Increase JACK's latency (either in qjackctl or on the jackd command line).
  Unfortunately this can cause audible delays, which might or might not
  matter (depending on what you're doing).

- Rebuild the kernel with the 'low latency desktop' option (aka HZ=1000).

- Add 'append="threadirqs"' to the kernel's options in /etc/lilo.conf, and
  install system/rtirq.

- Patch the kernel with the -rt (realtime) patch from
  https://www.kernel.org/pub/linux/kernel/projects/rt/

As an alternative to filesystem capability bits, it's possible to
use set_rlimits. See the set_rlimits SlackBuild in system/ for more
information.