On Sunday 07 December 2014 11:56:30 David Henningsson wrote:
> 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...
>
Yes and this is what in some situation I want!
It is useful in case when you have one desktop computer which is
used by two (or maybe more) trusted persons and each has own
profile.
Or if you have 2 (or more) users (in system) only because some
crappy applications support only one instance per user (session).
Or you have mobile phone (where is running pulseaudio) and you
want that all users should be able to use sound cards.
Another question, what about setting permission for pulse cookie
and shm file, so it can be accessed only by users in specific
group? Then it would not be accessible by all users.
> > 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).
Sounds good.
--
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/20141207/2e545851/attachment.sig>
