*** This bug is a duplicate of bug 1795649 ***
https://bugs.launchpad.net/bugs/1795649
@Mingun: I have replied in
https://bugs.launchpad.net/evince/+bug/1795649
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1969896
Title:
Evince Document Viewer(42.0) does not remember last page in 22.04 and
opens in a tiny window when launched
Status in apparmor package in Ubuntu:
Fix Released
Status in evince package in Ubuntu:
Invalid
Status in apparmor source package in Jammy:
Fix Released
Status in evince source package in Jammy:
Invalid
Status in apparmor source package in Kinetic:
Fix Released
Status in evince source package in Kinetic:
Invalid
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1969896/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
