Clicking a hyperlink in a PDF fails to open it if the default browser is a snap

[Olivier Tilloy]

[Impact]

 * Users cannot open a hyperlink in a PDF opened with evince when the default browser is a snap.
 * The fix creates a snap_browsers abstraction on AppArmor which can be used in a transition for when the browser is executed. The snap_browsers abstraction provides the minimal amount of permissions required to execute a browser provided through snaps. This is a workaround since AppArmor currently does not provide mediation/filtering on enhanced environment variables.

[Test Plan]

 * Make sure the default browser is provided through the snap store.
 * Open a PDF that contains a hyperlink using evince and click on the URL.
 * The browser should open the requested URL.

[Where problems could occur]

 * If the browser or snap core update to have new requirements for opening a browser, then the current policy could become obsolete and will need to be updated again.

[Olivier Tilloy (osomon)]

Note that this works with the evince snap, only the deb package is affected.

[Olivier Tilloy (osomon)]

I can "fix" the issue if I add the following two lines to /etc/apparmor.d/abstractions/ubuntu-browsers and reload the evince profile:

  /usr/bin/env rmix,
  /usr/bin/snap Cx -> sanitized_helper,

Probably not acceptable as is because this would allow executing any snap, not just chromium. And snaps are not guaranteed to be strictly confined (e.g. classic/devmode).

But a rule on /snap/bin/chromium is not good enough as /snap/bin/chromium is a symlink to /usr/bin/snap.

[Jamie Strandboge (jdstrand)]

I went through this the other day with a personal profile. We probably can do something along the lines of:

/{,snap/core/[0-9]*/}usr/bin/snap mrCx -> snap_browser,

profile snap_browser {
    #include <abstractions/base>

    /etc/passwd r,
    /etc/group r,
    /etc/nsswitch.conf r,
    /dev/tty rw,

    # noisy
    deny network inet stream,
    deny network inet6 stream,
    deny owner /run/user/[0-9]*/gdm/Xauthority r, # not needed on Ubuntu

    /{,snap/core/[0-9]*/}usr/bin/snap mrix, # re-exec
    /etc/fstab r,
    @{PROC}/sys/net/core/somaxconn r,
    @{PROC}/sys/kernel/seccomp/actions_avail r,
    owner @{PROC}/@{pid}/mountinfo r,
    owner @{HOME}/.snap/auth.json r, # if exists, required
    /run/snapd.socket rw,
    /snap/core/[0-9]*/usr/lib/snapd/info r,
    /snap/core/[0-9]*/usr/lib/snapd/snapd r,
    /var/lib/snapd/system-key r,

    /{,snap/core/*/}usr/lib/snapd/snap-confine Pix,
    /sys/kernel/security/apparmor/features/ r,

    # allow launching official browser snaps. This could be abstracted into an #include or tunable
    /snap/chromium/*/meta/snap.yaml r,
    /snap/firefox/*/meta/snap.yaml r,
    # ...
  }

[Olivier Tilloy (osomon)]

@Jamie, given your recent work on the evince apparmor profile, should that be assigned to you?

[Vladimir Kondratyev (vladimirkondratyev)]

After transition to snap the Chromium is not usable for me. I have a lot of PDFs with hyperlinks and they stopped working. Is there any workaround other then migrating to deb Chrome?

[Olivier Tilloy (osomon)]

This has come up again, now that the default browser in impish is the firefox snap (see https://discourse.ubuntu.com/t/feature-freeze-exception-seeding-the-official-firefox-snap-in-ubuntu-desktop/24210/107).

Jamie, I assume this should be unassigned, as you're not actively working on this, are you?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ian Johnson (anonymouse67)]

Also I'm not sure I agree with jdstrand's apparmor profile which includes:

    /run/snapd.socket rw,

which I don't think we want to grant to any PDF file opened with evince?

[Jamie Strandboge (jdstrand)]

Olivier, yes, I shouldn't be assigned. Ian, you're right the profile is suboptimal (it's also old so likely needs updating).

Do note that this is a separate named profile and evince (and if this is put in an abstraction, anything that uses the abstraction) only has the `/{,snap/core/[0-9]*/}usr/bin/snap mrCx -> snap_browser,` rule which means that it is able to run the 'snap' command (needed since everything in /snap/bin points to /usr/bin/snap) which at the time I wrote the profile meant that access to this socket was needed as part of snap run. IIRC, snapd should be protecting certain actions by uid connecting to it (eg, you are root or not), but it has been a while since I've looked at that. Evince is not a snap though so if snapd does any checks on 'is the client a snap' then those would fail and evince would be able to do whatever a non-root user could do with the 'snap' command via the socket.

For snap run, we can see that the snap_browser profile limits what can be used with 'run' since (at the time I wrote the comment) 'snap run' required being able to look at the meta/snap.yaml of the specific snap. This 'works' (worked?) but is brittle since if snap run changed to lift this requirement (eg, 'snap run' just passed the name of the unresolved symlink to snapd over the socket and let snapd start the snap, perhaps via userd, etc) then this falls apart.

The profile was put up as an example as what could be done at the time without any help from snapd. I never particularly cared for it cause it was brittle and not designed. I'm not sure how to fix this, but here are some thoughts:
* evince is just executing stuff from /snap/bin (probably via the system's xdg-open). Assuming xdg-open, the system's xdg-open (or whatever evince is using to decide and launch the default browser) could itself be fixed in Ubuntu to launch a different command that behaved better. This wouldn't necessarily fix other distros (though this is the evince profile in Debian and Ubuntu, so *technically*, if you got this change (to presumably xdg-open) into them, you could update the evince profile in them accordingly)
* In lieu of that, if the profile still worked as intended, snapd could be hardened to look to check more than if the connecting process is root or a snap; it could also see if it is running under a non-snap profile, then limit access to the socket API accordingly. This has drawbacks and could break people who have written custom profiles similar to what I presented.
* I suppose an alternative approach would be to have symlinks in /snap/bin for things that are registered as browsers (or just the default browser) point to a designed snap command. Eg:

  /snap/bin/firefox -> /usr/bin/snap # keep the existing one too
  /snap/bin/default-browser-is-a-snap -> /usr/bin/snap-browser # name is illustrative, TBD

  Now firefox, chromium, opera, brave, etc snaps registers themselves as being capable of being a default browser with snapd, then snapd registers with the system that /snap/bin/default-browser-is-a-snap is the default browser (so system utilities like xdg-open don't need to change) and /usr/bin/snap-browser is written to be saf...

[Georgia Garcia (georgiag)]

I was able to reproduce this issue on focal and bionic but not on impish. I'm still investigating why, since I don't see any changes in policies that might affect this issue, but I could have missed something.

[Alex Murray (alexmurray)]

Is there any option to do this via portals - ie can evince use https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.OpenURI to open the URI? Would then this allow to avoid going via xdg-open?

[John Johansen (jjohansen)]

I pulled the evince source and there does not appear to be any direct support for portals, and sandbox support is an untasked item on their roadmap. However it still may be possible via the gnome libs, or via dlopen. Those routes would need to be further investigated.

[Valentijn Sessink (valentijn)]

I'm running Jammy, upgraded from Focal, and this bug bites me:
(evince:56279): dbind-WARNING **: 12:05:26.897: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/1000/at-spi/bus: Permission denied

... then /var/log/syslog:
[...] audit: type=1400 audit(1649153341.153:384): apparmor="DENIED" operation="exec" profile="/usr/bin/evince" name="/usr/bin/snap" pid=56653 comm="env" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

[James Henstridge (jamesh)]

> Is there any option to do this via portals - ie can evince use
> org.freedesktop.portal.OpenURI to open the URI? Would then this
> allow to avoid going via xdg-open?

Evince is using g_app_info_launch_default_for_uri(), which can use the portal interface:

https://gitlab.gnome.org/GNOME/evince/-/blob/main/shell/ev-window.c#L6775-6778

However, it only does this as a fallback if no desktop file supports the URI. This is intended to allow a confined app to handle some file types within the sandbox before falling back to portals for everything else.

In the case of Evince running on the host system and seeing all the desktop files in /usr/share/applications and other locations, it likely won't ever call the portal API.

It'd be possible to code in explicit portal API calls, but it isn't something that Evince packaged as a flatpak or snap would need. So it might end up as a distro patch we'd be on the hook to maintain forever.

[Sebastien Bacher (seb128)]

it sounds like something that we should fix one way or another at least for the LTS, maybe in the futur we will have evince as a snap instead and the situation will be different. Could you suggest a patch for review with the change you described?

[Georgia Garcia (georgiag)]

I'm working on a SRU for apparmor and evince to introduce the snap_browsers abstraction on apparmor as a workaround for this issue.
It is based on these two merge requests from upstream:
https://gitlab.com/apparmor/apparmor/-/merge_requests/806
https://gitlab.com/apparmor/apparmor/-/merge_requests/877

[Sebastien Bacher (seb128)]

@Georgia, great, should we assign the apparmor line of the bug to you?

[Georgia Garcia (georgiag)]

@Sebastien, yes, just did. Thank you!

I also attached the debdiffs for evince and apparmor for bionic, focal, impish and jammy. They were also uploaded into the Security Proposed PPA:
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages?field.name_filter=apparmor
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages?field.name_filter=evince

[Sebastien Bacher (seb128)]

@Georgia, thanks for the work! Is anyone from the security team going to sponsor the apparmor updates for you?

Also in the evince debdiff, you added apparmor to the Build-Depends but is that needed? If the intend is to ensure a recent enough apparmor is available on the sytem then the Depends should be enough?

Also evince didn't depends on apparmor before, it's probably fine to change that but I still want to raise the question. What would be the outcome of installing the new evince with an old apparmor? would the missing rules just be ignored or would they create issues?

[Georgia Garcia (georgiag)]

@Sebastien, yes, I asked people from the security team to sponsor it but we are still reviewing the snap_browsers abstraction. We are denying access to /run/user/[0-9]*/gdm/Xauthority in the policy but if that was the case, then the browser should not have been able to open, but it does open so we are investigating if there's an issue.

Regarding the evince debdiff, even though it looks like the dependency is on Build-Depends on the debdiff, it is actually under Depends. If we don't set this dependency, then the snap_browsers abstraction might not be available. So if the new evince is installed with an old apparmor, then the evince apparmor policy will fail to load and evince will run unconfined.

[John Johansen (jjohansen)]

@georgiag we could move the abstraction include to "include if exists" to take care of the depends. Generally speaking evince shouldn't depend on apparmor, but of course make use of it if it is available.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Georgia Garcia (georgiag)]

I made some changes to the patches I submitted previously. In summary, I added permission to Xauthority files in the AppArmor abstraction and changed the dependency of AppArmor in Evince to "Recommends".
Please let me know if it looks okay or if there's any changes I should do
They are in
https://launchpad.net/~georgiag/+archive/ubuntu/test3/+packages

[Alex Murray (alexmurray)]

@georgia so the usual process (as per https://wiki.ubuntu.com/StableReleaseUpdates) from here would be to first get the changes into apparmor/evince in the current devel release (kinetic) and once it is verified that they are working fine there, then we backport them to jammy etc.

[RichardNeill (ubuntu-richardneill)]

Still broken, 17th September 2022 in Ubuntu 22.04.
Evince prints the following message "env: ‘/snap/bin/firefox’: Permission denied"
Workaround: https://github.com/popey/unsnap

[Ilya Popov (encyclopedist)]

Is there any update on the issue?

[Frédéric Grosshans (fgrosshans)]

The bug still exist on Kinetic.

[Romano Giannetti (romano-giannetti)]

Still here in 22.04 LTS; the workaround I use is the last one suggested in https://askubuntu.com/a/1428798/16395 (WARNING; that will allow evince to launch *any* snap in your system. But otherwise, evince is severely limited...)

[Steve Langasek (vorlon)]

Can someone provide a reference PDF showing this issue, to use in the SRU verification? (They are common, but we shouldn't have to hunt for one for the verification)

[Steve Langasek (vorlon)]

Found one locally that doesn't contain any confidential information, so attaching

[Steve Langasek (vorlon)]

Georgia, as noted in comment #31, it's better to use '#include if exists' than to add a versioned dependency on apparmor. Can you update the patches to do this and verify that it works as expected? Once this is done please resubscribe ~ubuntu-sponsors and we can get this done.

[Valentijn Sessink (valentijn)]

Here is one made for the very purpose of (not) being clickable.

[Georgia Garcia (georgiag)]

Hi Steve.
I updated the patches containing the requested changes and uploaded them to
https://launchpad.net/~georgiag/+archive/ubuntu/lp1794064/+packages
Please let me know if you prefer I attached the debdiffs here.

I'm resubscribing ~ubuntu-sponsors. Thanks

[Launchpad Janitor (janitor)]

This bug was fixed in the package evince - 44.1-1ubuntu1

---------------
evince (44.1-1ubuntu1) mantic; urgency=medium

  * Allow evince to spawn browsers distributed as snaps (LP: #1794064)
    - debian/apparmor-profile: include snap-browsers abstracted profile
      and allow transitions to them in evince

 -- Georgia Garcia <email address hidden> Mon, 05 Jun 2023 16:35:51 -0300

[Steve Langasek (vorlon)]

I see that there is an apparmor upload for this bug in the lunar queue, in addition to the evince upload. The apparmor upload adds a line to abstractions/snap_browsers. This bug report does not explain that the abstractions/snap_browsers was previously inadequate or that it should be updated to fix this bug. Please provide more information of why this apparmor change is needed.

[Steve Langasek (vorlon)]

Hello Olivier, or anyone else affected,

Accepted evince into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/evince/44.1-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

Hello Olivier, or anyone else affected,

Accepted apparmor into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/3.0.4-2ubuntu2.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Steve Langasek (vorlon)]

The evince upload to jammy still does:

+Recommends: default-dbus-session-bus | dbus-session-bus,
+ apparmor (>= 3.0.4-2ubuntu2.3),

with the explanation that:

+ - debian/control.in: recommend apparmor version that includes the
+ snap_browsers abstraction, or else policy loads will fail.

But the use of #include if exists was supposed to make this unnecessary. And downgrading the Depends to a Recommends doesn't change the default behavior here; installing this version of evince will by default pull in apparmor, even in contexts where apparmor was not previously installed. (There are not many of those in Ubuntu, which means if apparmor was not installed it was probably deliberate on the part of the admin!)

I'm rejecting this upload, as to my understanding this is not what we're meant to have.

[Steve Langasek (vorlon)]

An upload of evince to jammy-proposed has been rejected from the upload queue for the following reason: "adds Recommends that shouldn't be needed".

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted apparmor (3.0.4-2ubuntu2.3) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

dbus/1.12.20-2ubuntu4.1 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#apparmor

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 3.0.8-1ubuntu3

---------------
apparmor (3.0.8-1ubuntu3) mantic; urgency=medium

  * Update abstractions/snap-browsers to include lock permissions
    (LP: #1794064)
    - d/p/u/update-snap-browsers-permissions-lp1794064.patch

 -- Georgia Garcia <email address hidden> Tue, 06 Jun 2023 08:52:13 -0300

[Georgia Garcia (georgiag)]

Steve, the snap_browsers abstractions needed an update because the abstraction had not been updated in an year and the snap browsers now required read and lock permissions to the file /var/lib/snapd/inhibit/{browser-name}.lock, but this was also submitted, approved and merged upstream: https://gitlab.com/apparmor/apparmor/-/merge_requests/1045

Regarding the patch for evince, I kept the "Recommends" because, yes, the include if exists checks if the abstraction is present and it only includes in the case it is, but the actual rule which references the snap_browsers profile could fail for apparmor versions for which snap_browsers does not exist.
/{,snap/core/[0-9]*/,snap/snapd/[0-9]*/}usr/bin/snap mrCx -> snap_browsers,

[Steve Langasek (vorlon)]

I have confirmed that the updated evince, without an updated apparmor, fails in lunar with this error on stderr from evince:

internal error, please report: running "chromium" failed: open /var/lib/snapd/inhibit/chromium.lock: permission denied

that looks sufficient to me to move forward with this SRU, with the existing test case.

[Steve Langasek (vorlon)]

Hello Olivier, or anyone else affected,

Accepted apparmor into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/3.0.8-1ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Georgia Garcia (georgiag)]

I have verified on lunar with both apparmor and evince packages updated from the proposed pocket, it works as expected.

[Andreas Hasenack (ahasenack)]

evince and apparmor for lunar should be released together to fix this bug, but there is still a DEP8 failure that needs clearing under apparmor: libreoffice/armhf

https://ubuntu-archive-team.ubuntu.com/proposed-migration/lunar/update_excuses.html#apparmor

It was retried a few times already, but still fails. This is a very long test, 5-6h, andlibreoffice/armhf is already in the big_packages DEP8 queue, which gives it a bigger VM.

I triggered it one more time.

Ah, and besides that, apparmor has been in proposed for just 5 days, not the required 7.

[Jeremy Bícha (jbicha)]

The autopkgtest passed for apparmor lunar libreoffice/armhf

[Sebastien Bacher (seb128)]

Do we need evince to be reuploaded for jammy there since the previous upload was rejected by Steve?

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 3.0.8-1ubuntu2.1

---------------
apparmor (3.0.8-1ubuntu2.1) lunar; urgency=medium

  * Update abstractions/snap-browsers to include lock permissions
    (LP: #1794064)
    - d/p/u/update-snap-browsers-permissions-lp1794064.patch

 -- Georgia Garcia <email address hidden> Tue, 06 Jun 2023 08:49:17 -0300

[Andreas Hasenack (ahasenack)]

The verification of the Stable Release Update for apparmor has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Andreas Hasenack (ahasenack)]

> Do we need evince to be reuploaded for jammy there since the previous upload was rejected by Steve?

I'm trying to see what type of error we get if we load a profile with such a rule and the target profile does not exist:

  /{,snap/core/[0-9]*/,snap/snapd/[0-9]*/}usr/bin/snap mrCx -> snap_browsers,

Will it be worse than what we have now?
Will evince's postinst fail when it reloads the profile with the above line, and snap_browsers is not defined?
Will it crash when a link in a pdf is clicked?

It's taking a bit to setup a jammy desktop vm to try this, and I have other SRUs to process. Georgia, could you elaborate on what would happen if the new evince were to be installed with an old apparmor that knows nothing about the snap_browsers profile?

[Jeremy Bícha (jbicha)]

Andreas, Debian Testing right now has the updated evince but not the updated apparmor. https://bugs.debian.org/1040481

The consequence is that hyperlinks from Evince don't open if the default browser is a Snap. That's the same consequence as before the Evince change.

[Andreas Hasenack (ahasenack)]

Looks like we get this if evince is update, apparmor is not, and a link in a pdf is clicked:

Jul 06 18:36:59 j-evince kernel: audit: type=1400 audit(1688668619.304:78): apparmor="DENIED" operation="exec" info="profile transition not found" error=-13 profile="/usr/bin/evince" name="/usr/bin/snap" pid=2246 comm="env" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

The end result seems the same: permission denied, link isn't opened, the evince gui just does nothing, the console (if launched from a terminal) saya "env: '/snap/bin/firefox': Permission denied

If Georgia can confirm this is the worst that can happen by not having the Recommends on the updated apparmor profile, then I think it's ok to leave it out, but would be good to have confirmation from @vorlon, as he raised the objection and it's not clear if he saw Georgia's comment.

[Georgia Garcia (georgiag)]

Andreas, Jeremy, you are correct. The worst that could happen is the same behavior we have currently: when we click a URL the browser does not open, we get a denied log and evince prints "Permission denied".

My previous statement that profile loading could fail if apparmor did not find "snap_browsers" was a mistake. Evince installs successfully and apparmor loads the evince policy correctly. The apparmor service also does not fail if restarted.

I updated the evince package for jammy removing the "Recommends" in the ppa I shared previously if needed:
https://launchpad.net/~georgiag/+archive/ubuntu/lp1794064/+packages

Thank you all and I'm sorry for the confusion.

[Launchpad Janitor (janitor)]

This bug was fixed in the package evince - 44.1-1ubuntu0.1

---------------
evince (44.1-1ubuntu0.1) lunar; urgency=medium

  * Allow evince to spawn browsers distributed as snaps (LP: #1794064)
    - debian/apparmor-profile: include snap-browsers abstracted profile
      and allow transitions to them in evince

 -- Georgia Garcia <email address hidden> Mon, 05 Jun 2023 16:32:15 -0300

[Andreas Hasenack (ahasenack)]

Apparmor in jammy-proposed has the necessary changes, we just need a new evince upload to jammy without the recommends then.

[Andreas Hasenack (ahasenack)]

Hi Georgia, is this still pending an evince fix? Your PPA has an updated evince package, but I don't think it was uploaded to unapproved yet, without the recommends.

[Georgia Garcia (georgiag)]

Hi! You're right, I forgot to request a sponsorship.

I uploaded the patch for evince/jammy, could you take a look and sponsor if possible? Thanks

[Georgia Garcia (georgiag)]

Reuploading because I had a conflicting version with what was rejected in -proposed

[Graham Inggs (ginggs)]

Uploaded as 42.3-0ubuntu3.1, because we can re-use version numbers that never make it into the archive.

[Timo Aaltonen (tjaalton)]

Hello Olivier, or anyone else affected,

Accepted evince into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/evince/42.3-0ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted evince (42.3-0ubuntu3.1) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

apparmor/3.0.4-2ubuntu2.2 (amd64, arm64, armhf, ppc64el, s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#evince

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Sean Lanigan (ingenuity-sean)]

I have tested evince 42.3-0ubuntu3.1 and apparmor 3.0.4-2ubuntu2.3 from jammy-proposed, the bug appears to be fixed - I can now click hyperlinks from PDFs in Evince and Firefox as a Snap package correctly opens a new tab

[Georgia Garcia (georgiag)]

The autopkgtests for apparmor failed for the evince update because the test requires the apparmor update which is also in proposed https://launchpad.net/ubuntu/+source/apparmor/3.0.4-2ubuntu2.3 but it is not a regression.

[Chris Halse Rogers (raof)]

Retriggered the autopkgtest to use the correct apparmor version; let's see if that fixes things.

[Chris Halse Rogers (raof)]

Ah, jbicha had already retriggered the autopkgtests, and they now pass. Huzzah!

[Launchpad Janitor (janitor)]

This bug was fixed in the package evince - 42.3-0ubuntu3.1

---------------
evince (42.3-0ubuntu3.1) jammy; urgency=medium

  * Allow evince to spawn browsers distributed as snaps (LP: #1794064)
    - debian/apparmor-profile: include snap-browsers abstracted profile
      and allow transitions to them in evince.

 -- Georgia Garcia <email address hidden> Thu, 19 Oct 2023 16:01:41 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 3.0.4-2ubuntu2.3

---------------
apparmor (3.0.4-2ubuntu2.3) jammy; urgency=medium

  * Add support for applications like evince opening browsers
    distributed as snaps (LP: #1794064)
    - d/p/u/add-snap-browsers-profile-lp1794064.patch: add
      a snap-browsers abstraction profile to let applications like
      evince spawn browsers distributed as snaps
    - d/p/u/update-snap-browsers-permissions-lp1794064.patch: update
      snap-browsers abstraction with missing permissions

 -- Georgia Garcia <email address hidden> Mon, 05 Jun 2023 15:58:43 -0300

[Gerard (gbosch)]

Hi, I'm on Ubuntu 23.10 using Brave browser SNAP and I still face the issue (cannot open links in evince -using Brave browser snap).

Here are the versions:

```console
❯ apt list --installed | rg 'evince|apparmor'

apparmor/mantic,now 4.0.0~alpha2-0ubuntu5 amd64 [installed,automatic]
evince-common/mantic,mantic,now 45.0-1 all [installed,automatic]
evince/mantic,now 45.0-1 amd64 [installed]
libapparmor1/mantic,now 4.0.0~alpha2-0ubuntu5 amd64 [installed,automatic]
```
Brave Browser 120.1.61.101

`journalctl -f` log:

```console
Dec 20 12:18:37 laptop kernel: audit: type=1400 audit(1703071117.044:3565): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/evince//snap_browsers" name="/proc/cgroups" pid=1351803 comm="brave" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Dec 20 12:18:37 laptop brave_brave.desktop[1351803]: internal error, please report: running "brave" failed: open /snap/brave/323/meta/snap.yaml: permission denied
Dec 20 12:18:37 laptop kernel: audit: type=1400 audit(1703071117.052:3566): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/evince//snap_browsers" name="/snap/brave/323/meta/snap.yaml" pid=1351803 comm="brave" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

```

I see the following in `/etc/apparmor.d/usr.bin.evince` with all includes commented, including `snap_browsers` line. Is that normal? Thanks

```
       │ File: /etc/apparmor.d/usr.bin.evince
       │ Size: 11.5 KB
───────┼────────────────────────────────────────────────────────────────────────
   1 │ # vim:syntax=apparmor
   2 │
   3 │ # evince is not written with application confinement in mind and is designed to
   4 │ # operate within a trusted desktop session where anything running within the
   5 │ # user's session is trusted. That said, evince will often process untrusted
   6 │ # input (PDFs, images, etc). Ideally evince would be written in such a way that
   7 │ # image processing is separate from the main process and that processing
   8 │ # happens in a restrictive sandbox, but unfortunately that is not currently the
   9 │ # case. Because evince will process untrusted input, this profile aims to
  10 │ # provide some hardening, but considering evince's design and other factors such
  11 │ # as X, gsettings, accessibility, translations, DBus session and system
  12 │ # services, etc, complete confinement is not possible.
  13 │
  14 │ #include <tunables/global>
  15 │
  16 │ /usr/bin/evince {
  17 │ #include <abstractions/audio>
  18 │ #include <abstractions/bash>
  19 │ #include <abstractions/cups-client>
  20 │ #include <abstractions/dbus-accessibility>
  21 │ #include <abstractions/evince>
  22 │ #include <abstractions/ibus>
  23 │ #include <abstractions/nameservice>
  24 │
  25 │ #include <abstractions/ubuntu-browsers>
  26 │ #include <abstractions/ubuntu-console-browsers>
  27 │ #include <abstractions/ubuntu-email>
  28 │ #include <abstractions/ubuntu-console-email>
  29 │ #include <abstractions/ubuntu-media-players>
  30 │
  31 │ # allow evince to spawn browsers distributed as snaps (LP: #1794064)
  32 │ #...

[Georgia Garcia (georgiag)]

Hi Gerard

Brave does not work currently because we only added support to Chromium, Firefox and Opera as you can see in the current snap_browsers abstraction [1]. I'm adding Brave support as well [2].
While that change is not applied to the apparmor package, as a workaround, you could apply the same changes from [2] in /etc/apparmor.d/abstractions/snap_browsers and reload the evince profile
sudo apparmor_parser -r /etc/apparmor.d/usr.bin.evince

In regards to #include, it is not commented out. The apparmor policy allows the "include" keyword to be preceded by # or not. That said, #include is now being deprecated due to this exact confusion and we recommend using it without #.

[1] https://gitlab.com/apparmor/apparmor/-/blob/31c9cf6845cb78cca59a753d7c5b27312d579be8/profiles/apparmor.d/abstractions/snap_browsers
[2] https://gitlab.com/apparmor/apparmor/-/merge_requests/1137