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
