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)
-
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)
-
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
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
** Tags removed: rls-ff-incoming
--
You received this bug notification because you are a member of Ubuntu
Touch seeded 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
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 Ubuntu
Touch seeded packages, which is subscribed to
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
** Changed in: pulseaudio (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1886854
Title:
Race in load-module snap policy check
** Tags added: focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded 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
** Changed in: pulseaudio (Ubuntu)
Assignee: (unassigned) => James Henstridge (jamesh)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1886854
Title:
Race in
** Tags added: rls-ff-incoming
--
You received this bug notification because you are a member of Ubuntu
Touch seeded 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
14 matches
Mail list logo
