Fred, I have posted this before but the thread seemed to end at my post and I don't think it got a response.
On Mon, Mar 6, 2017 at 8:50 AM, Fred Gleason <[email protected]> wrote: > 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. > "One thing that I would like to see is an rd.conf option that would let us spell out which user should run caed and jack. I do not enjoy doing this as root when I let rivendell start jack. Or is the ability already there and I am just being a bit dense?" I think I want the possibility to run the audio/caed/jack stuff as a third user. Not root and not the rduser. I think I then want to set things up with sudo so that the rduser can launch jack apps as this third user. I can't remember right now the particular pain that caused me to want this the last time, but I do remember wanting it multiple times over the years. Can you see of any reason this would not be possible? > > Cheers! > > > |----------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |----------------------------------------------------------------------| > | A room without books is like a body without a soul. | > | -- Cicero | > |----------------------------------------------------------------------| > > all the best, drew -- Bahamain Or Nuttin - http://www.bahamianornuttin.com <http://www.bahamianornuttin.com/>
_______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
