Snap apparmor denial binding to dbus
Categories
(Release Engineering Graveyard :: Release Automation: Snap, defect)
Tracking
(firefox59 fix-optional, firefox60 affected)
Tracking | Status | |
---|---|---|
firefox59 | --- | fix-optional |
firefox60 | --- | affected |
People
(Reporter: ken.vandine, Assigned: ken.vandine)
References
(Blocks 1 open bug)
Details
Attachments
(1 obsolete file)
Assignee | ||
Comment 1•7 years ago
|
||
Comment 3•7 years ago
|
||
Assignee | ||
Comment 4•7 years ago
|
||
Comment 5•7 years ago
|
||
Assignee | ||
Comment 6•7 years ago
|
||
Comment 7•7 years ago
|
||
Assignee | ||
Comment 8•7 years ago
|
||
Comment 9•7 years ago
|
||
Assignee | ||
Comment 10•7 years ago
|
||
Comment 11•7 years ago
|
||
Updated•7 years ago
|
Comment 13•4 years ago
|
||
(In reply to Ken VanDine from comment #8)
Our security team suggested perhaps you could use the same well-known dbus
name and differentiate the profiles with different paths. That way we could
still safely confine the snap and still allowing access to bind to the dbus
name.
I'm not sure how that would work: each firefox instance is tied to a given profile, and we can't have two instances claim the same well-known bus name, can we?
Comment 14•4 years ago
|
||
Related discussion on the snapcraft forum.
Comment 15•4 years ago
|
||
Will that change make it into snapd in time for 89 or should we make a local change?
Comment 16•4 years ago
|
||
According to their roadmap, snapd 2.50 is scheduled for a stable release on May 12th, so it seems very unlikely that the change that I'm proposing would be accepted into the release branch before then.
What sort of local change are you thinking about?
Comment 17•4 years ago
|
||
Your comment here:
"A temporary band-aid would be to have the firefox snap claim the org.mozilla.firefox.ZGVmYXVsdA__ slot, because this corresponds to the profile named “default”. This would at least make the most common use case (one single profile with the default name) work:"
Comment 18•4 years ago
|
||
Yes, I suppose we can do that until this is properly addressed in snapd.
Comment 19•4 years ago
|
||
Comment 20•4 years ago
|
||
Good news, my snapd patch was merged and cherry-picked into the 2.50 branch, and I was informed that it will be part of snapd 2.50.1, scheduled for release in ~2weeks.
Comment 21•4 years ago
|
||
Good news, my snapd patch was merged and cherry-picked into the 2.50 branch, and I was informed that it will be part of snapd 2.50.1, scheduled for release in ~2weeks.
Awesome! So should we wait to close this until we can test with the new snapd?
Comment 22•4 years ago
|
||
Awesome! So should we wait to close this until we can test with the new snapd?
Yes. Actually, this can be tested now, with snapd from the edge channel (snap refresh snapd --edge
).
Just tested here, and this appears to work correctly. So I'm going to close D114774.
Updated•4 years ago
|
Comment 23•4 years ago
|
||
This bug was fixed in snapd and doesn't require further work in firefox, so it can now be closed.
Comment 24•4 years ago
|
||
(In reply to Olivier Tilloy from comment #23)
This bug was fixed in snapd and doesn't require further work in firefox, so it can now be closed.
Thanks for the heads-up, closing now.
Updated•1 year ago
|
Description
•