Merge lp://qastaging/~sdeziel/apparmor-profiles/refresh-pulseaudio into lp://qastaging/apparmor-profiles

On Thu, Jan 07, 2016 at 06:21:23PM -0000, Simon Déziel wrote:
> - /run/pulse/ rw,
> - /run/pulse/.pulse-cookie rwk,
> - /run/pulse/dbus-socket rwk,
> - /run/pulse/native rwk,
> - /run/pulse/pid rwk,
> + owner /run/pulse/ rw,
> + owner /run/pulse/.pulse-cookie rwk,
> + owner /run/pulse/dbus-socket rwk,
> + owner /run/pulse/native rwk,
> + owner /run/pulse/pid rwk,
> + owner /run/user/[0-9]*/pulse/ rw,
> + owner /run/user/[0-9]*/pulse/* rwk,
> /run/udev/data/+sound:card* r,
> + /run/udev/data/c116:[0-9]* r,
>

How does 'owner /run/pulse/' work? Are these paths bind-mounted from
per-user paths? Or are these paths when pulse is used as root in some
environments?

>
> owner /var/lib/lightdm/.Xauthority r,
> owner /var/lib/lightdm/.esd_auth rwk,
> - owner /var/lib/lightdm/.pulse-cookie rwk,
> - owner /var/lib/lightdm/.pulse/ rw,
> - owner /var/lib/lightdm/.pulse/* w,
> - owner /var/lib/lightdm/.pulse/* r,
> + owner /var/lib/lightdm/.config/pulse/cookie rwk,
> + owner /var/lib/lightdm/.config/pulse/ rw,
> + owner /var/lib/lightdm/.config/pulse/* rw,

Removing accesses like this may cause problems if the AppArmor profile is
replaced before any executing binaries that use the old pathnames. Are
these old path names unused for long enough that no executing binaries
currently use them?

Thanks

On 2016-01-07 02:30 PM, Seth Arnold wrote:
> On Thu, Jan 07, 2016 at 06:21:23PM -0000, Simon Déziel wrote:
>> - /run/pulse/ rw,
>> - /run/pulse/.pulse-cookie rwk,
>> - /run/pulse/dbus-socket rwk,
>> - /run/pulse/native rwk,
>> - /run/pulse/pid rwk,
>> + owner /run/pulse/ rw,
>> + owner /run/pulse/.pulse-cookie rwk,
>> + owner /run/pulse/dbus-socket rwk,
>> + owner /run/pulse/native rwk,
>> + owner /run/pulse/pid rwk,
>> + owner /run/user/[0-9]*/pulse/ rw,
>> + owner /run/user/[0-9]*/pulse/* rwk,
>> /run/udev/data/+sound:card* r,
>> + /run/udev/data/c116:[0-9]* r,
>>
>
> How does 'owner /run/pulse/' work? Are these paths bind-mounted from
> per-user paths? Or are these paths when pulse is used as root in some
> environments?

It's in case pulse is used as root, I believe. I know this path doesn't
exist on my Xenial desktop.

>>
>> owner /var/lib/lightdm/.Xauthority r,
>> owner /var/lib/lightdm/.esd_auth rwk,
>> - owner /var/lib/lightdm/.pulse-cookie rwk,
>> - owner /var/lib/lightdm/.pulse/ rw,
>> - owner /var/lib/lightdm/.pulse/* w,
>> - owner /var/lib/lightdm/.pulse/* r,
>> + owner /var/lib/lightdm/.config/pulse/cookie rwk,
>> + owner /var/lib/lightdm/.config/pulse/ rw,
>> + owner /var/lib/lightdm/.config/pulse/* rw,
>
> Removing accesses like this may cause problems if the AppArmor profile is
> replaced before any executing binaries that use the old pathnames. Are
> these old path names unused for long enough that no executing binaries
> currently use them?

On Trusty, ~lightdm/.config/pulse is used so we should be good there.

Regards,
Simon

Thanks, LGTM

Thanks Seth!