This bug was fixed in the package pulseaudio - 1:11.1-1ubuntu7.11
---
pulseaudio (1:11.1-1ubuntu7.11) bionic-security; urgency=medium
* SECURITY UPDATE: don't rely on SCM_CREDENTIALS to detect snap confined
clients (LP: #1895928)
- d/p/0409-pa-client-peer-credentials.patch:
This bug was fixed in the package pulseaudio - 1:13.99.1-1ubuntu3.8
---
pulseaudio (1:13.99.1-1ubuntu3.8) focal-security; urgency=medium
* SECURITY UPDATE: don't rely on SCM_CREDENTIALS to detect snap confined
clients (LP: #1895928)
- d/p/0409-pa-client-peer-credentials.patc
This bug was fixed in the package pulseaudio - 1:13.99.2-1ubuntu2.1
---
pulseaudio (1:13.99.2-1ubuntu2.1) groovy-security; urgency=medium
* SECURITY UPDATE: don't rely on SCM_CREDENTIALS to detect snap confined
clients (LP: #1895928)
- d/p/0409-pa-client-peer-credentials.pat
The attachment "allow-classic.diff" seems to be a patch. If it isn't,
please remove the "patch" flag from the attachment, remove the "patch"
tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the
team.
[This is an automated message performed by a Launchpad user owned by
~brian-mur
This is the in-progress fix I've been working on. It does not quite
work right though: switching to an async hook for these commands is
resulting in the daemon killing the client on a protocol error.
This might be a problem with the hooks patch set itself. I need to
investigate a bit further.
*
Sorry for taking so long to get back to you. I now understand the non-
deterministic behaviour you're seeing.
I'm working on a fix for the server side to allow classic snaps to
access these commands. It will require a small change to your Pulse
Audio client library to fix the non-determinism tho
** Tags removed: rls-ff-incoming
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1886854
Title:
Race in load-module snap policy check in classic confinement
Status in pulseaudio pa
Yes, I do believe it's the same PA instance, I had not noticed it
restarting (e.g. pavucontrol losing the connection) when testing around
this bug.
Also, I'm not sure if it helps, but the module likes to spam a ton of
pulseaudio[11451]: E: [pulseaudio] module-snap-policy.c: AppArmor profile
I think I need to dig into this further. The fact you're seeing a few
successful module loads with different module indexes would indicate it
is the same Pulse Audio instance.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in
I think there's two issues at play here.
The hooks we added for module loading/unloading as part of USN-4355-1
simply check if the client has an AppArmor label that looks like it
belongs to a snap and denies access if found. This will also deny
access to classic snaps, which is probably a mistake
** Changed in: pulseaudio (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1886854
Title:
Race in load-module snap policy check in classic c
** Tags added: focal
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1886854
Title:
Race in load-module snap policy check in classic confinement
Status in pulseaudio package in Ubu
** Changed in: pulseaudio (Ubuntu)
Assignee: (unassigned) => James Henstridge (jamesh)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1886854
Title:
Race in load-module snap p
** Tags added: rls-ff-incoming
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1886854
Title:
Race in load-module snap policy check in classic confinement
Status in pulseaudio pack
14 matches
Mail list logo
