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.
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.
--
Tanu
