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...
--
Pali Rohár
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20141209/9defdb83/attachment.sig>
