On Feb 28, 2017, at 09:05, Alessio Elmi <[email protected]> wrote:
> Just a recap of which are the presupposition: it has always been suggested to
> run Rivendell under dedicated user, something like a system user, different
> from the one which is 'graphically' logged in. For example you may want a
> simple-and-not-privileged user called 'studio', which cannot touch /var/snd
> folder. It can of course launch all Rivendell UI modules, and actually it
> does. On the other hand Rivendell daemons, caed/ripcd/rdcatchd run under
> 'rivendell' user, who hasn't any active X session, and it is the owner of
> /var/snd. A nice way of accomplish this security framework is to setuid the
> three binary daemons with chown rivendell:rivendell and then chmod 4755. So
> far, so good.
>
> Any problem with the above scenario? Are there newer recommendations?
That is the current setup with BroadcastAppliance-based systems.
> Problems come up if you want to use jack server to handle audio resources. In
> fact, any applications looking for a jack server can only see instances
> running under the same user identity. If 'studio' runs 'jackd', this cannot
> be seen by 'caed', which is launched by 'rivendell'. You need to setuid also
> jackd the same way you did for caed. This is the only solution I found. But
> as you can imagine, this workaround leads to a domino effect, where any
> jack-related application must be setuid, otherwise it cannot work. And of
> course you cannot use any graphical tool, like qjackctl/patchage since they
> need an X server owned by the same jack-server user.
>
> There is another strange behavior I need to investigate better (you may
> confirm). If jack server is not setuid (just chmod 0755), and launched
> through systemd with a specific user, then caed cannot see it, even though
> users match. But this is not a big deal in the end.
>
> It is a pity. Jack is a very versatile tool. Since the computer is used for
> production purposes, I really would like users to listen to Youtube with the
> same audio card linked to RDLibrary.
This is basically a problem with JACK. My understanding is that it is due to
overly restrictive permissions applied to the shared memory segments that jackd
uses for its IPC. Theoretically at least, it could be addressed by widening
those permissions, though this also has security implications that would need
to be analyzed and addressed. Their developer community is aware of it (and at
one point even had a patch that would permit multiple users to share the same
jackd instance), but at present don’t seem to be overly motivated to do
anything about it. For example, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500249
Googling JACK_PROMISCUOUS_SERVER should bring up lots of info.
Cheers!
|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| A room without books is like a body without a soul. |
| -- Cicero |
|----------------------------------------------------------------------|
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
