Code review comment for lp:~sdeziel/apparmor-profiles/refresh-pulseaudio

Revision history for this message
Simon Déziel (sdeziel) wrote :

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

« Back to merge proposal