[PlanetCCRMA] the jack permissions conundrum

[Simon Lewis]

Hi Fernando

Please correct me if I am wrong...

You a describing a collection of configuration files to be put in the 
folder '/etc/security/limits.d' and the file '/etc/pam.d/system-auth' . 
The configuration files in the limits.d folder replace entries made in 
file '/etc/security/limits.conf'. These configuration files allow a user 
and/or group and/or application to use real-time scheduling. Whereby:
user:  all users, named user
group: audio, jackuser, pulseaudio, etc..
application: jack-audio-connection-kit, energy-XT2, libffado, etc..

The configuration files are not derived from the 
jack-audio-connection-kit source code. However, for jackd to run 
correctly, the jack-audio-connection-kit package depends upon 
(Requires:) the package containing the configuration files.

Following the fedora/planerccrma naming convention the packaged 
containing the configuration files should be named something like:

planetccrma-core-config.noarch

This package could conceivably include indexing for snd-drivers for usb 
and firewire sound cards.

Since the user should not need to manually edit conf files I would 
suggest to give all users rt-sscheduling as is the case now.

Simon



Am 24.05.2010 21:38, schrieb Fernando Lopez-Lezcano:
> I'm trying to decide what to do with regards to permissions management
> for jack (including firewire devices) in the Planet CCRMA
> jack-audio-connection (1.9.x) packages.
>
> The current situation is AFAICT:
>
> - Fedora jack1 packages allows users access to realtime scheduling and
> memory locking only if the user belongs to a particular group
> (jackuser?).
>
> - Planet CCRMA jack2 packages allows all users access to realtime
> scheduling and locking by default.
>
> Furthermore, access to firewire devices (needed for the ffado library
> and jack backend to work) is not enabled by default in any version of
> jack (I was/am enabling access to raw1394 through console.perms.d/ but I
> suspect that is now deprecated in newer versions of Fedora - does anyone
> know for sure which mechanism is used in each recent version of
> Fedora??).
>
> So.......
>
> a) I could move the Planet CCRMA package to the Fedora group based
> permissions, and add a sub-package to the current Planet CCRMA
> jack-audio-connection-kit build so that, if installed, it will grant
> full access to all users, something like:
>
>    jack-audio-connection-kit-full-access
>
> (can anyone think of a better name? this one is not very good)
>
> BTW, I don't know if a second udev rule with global permissions would
> override another one for the same device with group permissions... so
> this may not be possible.
>
> So in this case you would get the same permissions as Fedora by default
> and you would install another sub-package to get the current full
> permissions. Maybe planetccrma-core would have that requirement built-in
> so that the current behavior is kept.
>
> b) I could split out the permissions entirely out of the base
> jack-audio-connection-kit package so that we have two sub-packages:
>
>    jack-audio-connection-kit-full-access
>
> and
>
>    jack-audio-connection-kit-group-access
>
> Each would grant access of realtime scheduling, memory locking and
> firewire devices to either all users or just users that belong to a
> certain group (which would be jackuser - or whatever it is named - to
> match what Fedora does).
>
> In this case you would explicitly choose at install time which type of
> access you want by installing the proper jack-1.9.x sub-package.
>
> Opinions?
> -- Fernando
>
>
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20100525/71df592e/attachment.html