On Dec 2, 2021, at 08:25, Florent Peyraud <fpeyr...@rivendell-fr.org> wrote:

> unfortunately, either promiscuous mode in jack or system-wide daemon in 
> pulse-audio are configurations not recommended nor supported. And as I'm 
> trying to provide a solution for average users and rivendell administrators, 
> who are not necessarily system administrators, I would like to avoid as much 
> as possible unsupported or not recommended solutions. Moreover, since it 
> deals with shared memory, relaxing permissions on such files may introduce 
> security flaws.

Well, it all depends on your use case. But first, the low-hanging fruit: 
PulseAudio.

The use case for which PulseAudio was designed is ‘general desktops’ —i.e. 
playing the various beeps, boops and other sound effects generated by a GUI in 
the course of its normal operation when running typical ‘office automation’ 
type applications (web browsers, word processors, etc). As such, it has no 
place on a system designed to handle pro audio. It’s one of the first things I 
typically disable on any new Rivendell system.

As for JACK’s promiscuous mode, I’m not quite sure what you mean by calling it 
‘unsupported’. It’s present in the stock tarballs and binary downloads 
available at the canonical JACK GitHub site, so it’s certainly ’supported’ by 
the primary JACK developers. Whether its use is *appropriate* in a given 
situation is a matter of professional judgement. Does it open new avenues by 
which a system could be compromised in some way? Sure. So does giving a user an 
account on the system. So does turning on the power on the computer in the 
first place. I think the more relevant question to ask is: does it provide 
additional capabilities sufficient to justify the additional risk? The standard 
security principle of ‘least privilege’ holds that a user should have no more 
power on a system than the minimum necessary to do their required tasks. Given 
that Rivendell's previous, “non-promiscuous mode” JACK setup required that 
users run all JACK audio applications as ‘root’, I have to imagine that this 
change makes for a vastly improved security posture in general.


> By the way, I could not find a way to start Jackd in promiscuous mode through 
> dbus. If you have any clue, I would be pleased to test it

Unfortunately, the only way I’ve found to enable it is to define a 
$JACK_PROMISCUOUS_SERVER variable in the environment and then export that to 
jackd(1) as well as every audio application that will be using it. There are a 
number of drawbacks to this approach, the primary one in Rivendell’s case being 
that there is no easy way to give the feature a convenient user-facing ON/OFF 
switch (with, say, a checkbox in RDAdmin). Instead, it’s got to be baked-in to 
a number of static configuration files on the system. There are various values 
that can be given to that environmental variable that influence how it works; 
see the ENVIRONMENT section of the jackd(1) man page for specifics. AFAICT, 
there is no way to enable/disable it via dbus.

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|   Liberty is always dangerous, but it is the safest thing we have.  |
|                                                                     |
|                                          -- Harry Emerson Fosdick   |
|---------------------------------------------------------------------|
_______________________________________________
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Reply via email to