[pulseaudio-discuss] System mode & SHM

[David Henningsson]

On 2014-12-06 23:20, Tanu Kaskinen wrote:
> On Sun, 2014-11-23 at 14:43 +0100, Pali Rohár wrote:
>> On Sunday 23 November 2014 09:25:46 David Henningsson wrote:
>>> On 2014-11-22 22:39, Pali Rohár wrote:
>>>> Hello,
>>>>
>>>> it is possible to enable shared memory when pulseaudio is
>>>> stared in system mode?
>>>
>>> Not without recompiling PulseAudio, the relevant code is in
>>> src/pulsecore/protocol_native.c, function command_auth:
>>>
>>> #ifdef HAVE_CREDS
>>>       if (do_shm) {
>>>           /* Only enable SHM if both sides are owned by the
>>> same * user. This is a security measure because otherwise
>>> data * private to the user might leak. */
>>>
>>>           const pa_creds *creds;
>>>           if (!(creds = pa_pdispatch_creds(pd)) || getuid() !=
>>> creds->uid) do_shm = false;
>>>       }
>>> #endif
>>>
>>> Maybe there's more stuff that needs to be changed as well, I
>>> don't know.
>>
>> Ok, so what about adding parameter which force SHM support if
>> user/administrator/owner of system want to do that?
>
> That sounds like a good idea.

I'm hesitating. I'm not saying I'm totally against it, but the security 
implications are somewhat scary - I assume this means you have to open 
up the shm files to the world, which means all users can spy on each 
other's audio. The srbchannel shm file will also be writable by all 
users, so one user can potentially enter commands in another user's 
stream...

> It's a bit tricky to define the configuration syntax, though. We
> currently have the "enable-shm" option in daemon.conf, and that seems
> like the appropriate option to use here. Currently, "no" means "no" and
> "yes" means "yes, if shm is available and if we're not running in the
> system mode". We'd need a third option that would have the semantics of
> "yes, if shm is available". I don't know what the third option should be
> named. I'd want "yes" to refer to the new option, and introduce
> "user-mode-only" to refer to the current "yes", but that's not a good
> choice, because we should keep the old semantics attached to the old
> option values for compatibility reasons. I suggest
> "yes-also-in-system-mode" for the new option, but I really hope someone
> comes up with something better.

If implemented, I think we should follow existing semantics (for 
consistency), like how we deal with "--disallow-module-loading" in 
system mode (i e print a warning).


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic