[pulseaudio-discuss] [PATCH 00/11] Introduce memfd support

[Ahmed S. Darwish]

Hi Alex,

On Mon, Sep 21, 2015 at 09:06:52AM +0200, Alexander Larsson wrote:
> On sön, 2015-09-20 at 23:21 +0200, Ahmed S. Darwish wrote:
> > Hi everyone,
> > 
> > This RFC patch series introduces memfd support [*] to PulseAudio,
> > laying out the necessary (but not yet sufficient) groundwork for
> > sandboxing, protecting PulseAudio from its clients, and protecting
> > clients (data) from each other.
> 
> So, I don't actually know pulseaudio well enough to review this patch,
> but YEAH MAN! cool!
>

Merci! I've just seen your GUADEC 2015 xdg-app session on Youtube,
specifically the notes on sandboxing and PulseAudio, so thought of
sending you a small ping on the latest developments here ;-)

BIG THANKS for your work on xdg-app, you're solving the #1 pain point
in Linux userspace!

>
> I'm currently making an update of the freedesktop and gnome
> sdk/runtime, and I guess if a pulseaudio 7 comes out soon I can put
> that in. However, I assume this is post-7 material?
>

v7 is indeed around the corner. Arun has just stated that it might
be released "in a couple of days." [1]

For memfds, this is only the very first submission. Reviews by the
PA maintainers, and a big number of further iterations resulting
from such reviews, is warranted ;-)

There is also a number of pending items mentioned in the cover
letter TODO section to make this transition complete and reach an
empty /dev/shm folder. Luckily, there's nothing insurmountable in
this TODO list though.

>
> Some questions:
> 
> Is there a way to force sandboxed clients to only use the new memfd
> support. (i.e. refusing to fallback to shm for some clients.)
>

Sure, upon the succesful completion of this patch series, a
'--disable-posix-shm' compile-time option can be created easily.
Better yet, a daemon configuration option for this can be created
and parsed at run time.

>
> Do you have any plans for how to do per-client permissions? In the most
> recent release of xdg-app I actually added support for a generic
> permissions store:
> 
>  http://cgit.freedesktop.org/xdg-app/xdg-app/tree/data/org.freedesktop.XdgApp.xml
> 
> The way it works is that you make up a table name, like "pulseaudio",
> and then you can set and query permissions on string ids, with some
> extra data stored with the id.
> 
> Basically the api is
>  struct app_permissions {
>    string app_id;
>    string permissions[];
>  }
>  Set(string table, string id, app_permissions[] perms, GVariant extra_data)
>  Lookup(string table, string id, out app_permissions[] perms, out GVariant extra_data)
>

So if I understood correctly, we can say that app_id `org.gnome.music`
has access to permission CONNECT_PLAYBACK, and app_id `org.gnome.Audacity'
has access to permissions CONNECT RECORD and CONNECT_PLAYBACK?

If so, this can work nicely with Wim's PA access control patch series
posted here:

  http://article.gmane.org/gmane.comp.audio.pulseaudio.general/23282

Note the hooks available: CONNECT_PLAYBACK, CONNECT_RECORD,
SET_SINK_VOLUME, and how they can be one-to-one mapped to permissions
in the "pulseaudio" xdg-app permission table mentioned above.

> There is also some sample code here:
>  http://cgit.freedesktop.org/xdg-app/xdg-app/tree/document-portal/xdp-util.c#n283
> Which looks up the xdg-app app-id for a dbus invocation which can be
> used as inspiration for how to do this in pulseaudio.
>

Hmmm .. commands sent from client to server (and vice versa) are done
through the low-latency "srbchannel" mechanism these days: a shared
ringbuffer + eventfds implementation; [2] no D-Bus is involved.

Nonetheless, I'll definitely chime in on this topic after making the
memfd support stable and upstreamable. I'm sure the core PA devs
also have a lot of valuable input in this topic too ;-)

Cheers,

[1] "Ready for 7.0?"
    http://article.gmane.org/gmane.comp.audio.pulseaudio.general/24123

[2] PulseAudio buffers and protocol, diwic
    http://voices.canonical.com/david.henningsson/2014/11/21/pulseaudio-buffers-and-protocol/

-- 
Ahmed Darwish
http://darwish.chasingpointers.com