Evince Document Viewer(42.0) does not remember last page in 22.04 and opens in a tiny window when launched
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apparmor (Ubuntu) |
Fix Released
|
High
|
Alex Murray | ||
Jammy |
Fix Released
|
High
|
Alex Murray | ||
Kinetic |
Fix Released
|
High
|
Alex Murray | ||
evince (Ubuntu) |
Invalid
|
High
|
Unassigned | ||
Jammy |
Invalid
|
High
|
Unassigned | ||
Kinetic |
Invalid
|
High
|
Unassigned |
Bug Description
[Impact]
* Evince does not behave as expected and launches with a very small window resulting in a poor user experience
* Fixing this requires only a minor change to the exo-open abstraction and results in correctly functioning evince
* By removing the dbus deny rule in the exo-open abstraction, evince is able to correctly communicate with gvfs and start up as normal
[Test Plan]
* Start dbus-monitor to watch for AppArmor denials
$ dbus-monitor --session | grep AppArmor
* Launch evince and there should be no AppArmor message shown above from dbus-monitor
[Where problems could occur]
* By removing this deny rule from the exo-open abstraction, AppArmor will be more permissive for anything which uses the exo-open abstraction and potentially allow it access to gvfs where it did not before.
* This should not result in any regressions as we are granting extra functionality which wasn't allowed before, however perhaps in the case of an application which expects *not* to be able to use gvfs as this was previously explicitly denied, it may now be able to (if it has a less specific allow rule) and hence it may function differently than before.
[Other Info]
* Whilst on the surface by removing this deny rule it may appear that this grants additional permissions to anything which uses the exo-open abstraction, this is not necessarily true as AppArmor denies all accesses by default unless explicitly allowed by a profile. And so in general this will not grant permission to use a DBus interface that an application did not have before. However, due to the way that deny rules take precedence over allow rules in AppArmor, if an application had been allowed generic dbus access to the user's session bus, the previous deny rule in the exo-open abstraction would then have denied them access to just gvfs via dbus. With this new proposed change, this is not explicitly denied and so is now allowed as expected. But for applcations which may have used the exo-open abstraction and which did *not* have DBus access before, this change will not result in them obtaining DBus access either.
tags: | added: desktop-lts-wishlist |
Changed in evince (Ubuntu): | |
status: | Incomplete → New |
Changed in evince (Ubuntu): | |
status: | Confirmed → In Progress |
tags: | added: dt-392 |
Changed in apparmor (Ubuntu Kinetic): | |
status: | Confirmed → In Progress |
Changed in apparmor (Ubuntu Jammy): | |
status: | New → In Progress |
Changed in apparmor (Ubuntu Kinetic): | |
assignee: | nobody → Alex Murray (alexmurray) |
Changed in apparmor (Ubuntu Jammy): | |
assignee: | nobody → Alex Murray (alexmurray) |
importance: | Undecided → High |
Changed in evince (Ubuntu Jammy): | |
status: | New → Confirmed |
description: | updated |
Changed in apparmor (Ubuntu Jammy): | |
status: | Fix Committed → Fix Released |
Changed in apparmor (Ubuntu Jammy): | |
status: | Fix Released → Fix Committed |
Status changed to 'Confirmed' because the bug affects multiple users.