Pulseaudio snap permissions

[Jamie Strandboge]

CC'ing Zygmunt as fyi for skills requirements

On Tue, 2016-02-09 at 14:00 +0100, David Henningsson wrote:
> Hi snappy-devel,
> 
> I've been working on packaging PulseAudio for snappy in order to
> enable 
> apps to play back audio. I've come as far as I need to have the 
> permissions conversation with someone more familiar with snappy.
> 
You probably want to talk to me. :) First off, is this for 15.04 or
16.04? If 16.04, as Mark said, we want to move to a skills-only
approach.

> PulseAudio needs to do at least these things:
> 
>   * Listen to a UNIX socket where clients can connect (there are a
> few 
> options w r t where this socket could be located so clients find it).
> 
This is possible with the 'socket' options in the yaml for 15.04. For
16.04, this is still available but I imagine this is going to change in
favor of a skills approach that is TBD for sockets.

>   * Access ALSA sound cards, i e ioctl device nodes under
> /dev/snd/*. 
> (Note: UNIX permissions of these nodes might need adjustment too 
> depending on solution)
> 
You would use hw-assign on 15.04 and the skills approach on 16.04 (not
yet implemented for /dev/snd/* devices).

>   * Listen to udev events to tell when new sound cards appear in the 
> system (e g, someone might connect a USB headset).
> 
You would need (hand-crafted) security-policy for this on 15.04. We'll
want to take a close look at what this is doing as I imagine this would
need to fall under an 'audio-manager' (or audio-managing) skill.

>   * Get on the system D-Bus in order to speak with the bluetooth
> daemon 
> (in order to enable audio I/O through bluetooth headsets).
> 
Use 'bus-name' and set 'type: framework' on 15.04. On 16.04, this, you
guessed it, will be skills based (not yet implemented but needed for
several things (eg, bluez)).

>   * Gain real-time priority in order to have low-latency audio
> working 
> without glitches.
> 
This sounds like a pure security skill.
> 
> Right now, I'm not sure whether PulseAudio should run as a user-level 
> or 
> system-level daemon - I expect this will affect what solutions we
> choose 
> for security too.
> 
Snappy doesn't currently have the concept of user services, so sounds
like system-level is the way to go for now.

> So far I've been working with customizing snapcraft.yaml only, but
> maybe 
> this reaches beyond what snapcraft can handle and some special
> apparmor 
> and/or seccomp profiles need to be crafted. Not sure about this
> either?

Once the skills work is farther along we'll define a way for people to
engage with the snappy team for requesting new skills. For now, I
suggest working with me on irc or off-list so I can help unblock you
and so we (zyga and I) can work out what this snap needs and can work
out the skills needed for 16.04.

-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160209/54c7b114/attachment.pgp>