On Tue, 2015-05-05 at 13:51 +0200, Pali Rohár wrote:
> On Tuesday 09 December 2014 22:58:07 Pali Rohár wrote:
> > On Sunday 07 December 2014 00:23:08 Tanu Kaskinen wrote:
> > > On Sat, 2014-12-06 at 23:59 +0100, Pali Rohár wrote:
> > > > On Saturday 06 December 2014 23:20:10 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.
> > > > >
> > > > > 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.
> > > >
> > > > Ok, then what about adding new option "enable-shm-in-system"
> > > > (or other name) which will be used for system mode and
> > > > current option "enable-shm" will be used only for user
> > > > mode?
> > >
> > > Yeah, maybe it's best to add another option. I'd suggest
> > > "allow-shm-in-system-mode", which would control whether
> > > "enable-shm = yes" has any effect in the system mode, but I
> > > don't feel too strongly about this - I'd be ok with your
> > > suggestion too (I think the option should say "system-mode"
> > > instead of just "system", though).
> >
> > "enable-shm-in-system-mode" or "allow-shm-in-system-mode"
> >
> > I think both looks ok...
> >
>
> Hello, something new about enabling SHM in system mode?
> Was some option name finally accepted?
Nothing new to my knowledge. Regarding naming, my vote goes to
"allow-shm-in-system-mode".
--
Tanu
