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 safe (eg, only able
to 'snap run' the configured default browser, nothing else) and apparmor
profiles are adjusted to have `/{,snap/core/[0-9]*/}usr/bin/snap-browser
Uxr,` (or similar). The /snap/bin/default-browser-is-a-snap path is
illustrative and there isn't really a need for it at all. Could simply
perhaps have snapd register /usr/bin/snap-browser as the default browser
on the system (it now needs to know what snapd configured as the default
browser snap though) and forego the symlink.
--
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/1794064
Title:
Clicking a hyperlink in a PDF fails to open it if the default browser
is a snap
Status in apparmor package in Ubuntu:
Confirmed
Status in evince package in Ubuntu:
Triaged
Bug description:
This is related to bug #1792648. After fixing that one (see discussion
at https://salsa.debian.org/gnome-team/evince/merge_requests/1),
clicking a hyperlink in a PDF opens it correctly if the default
browser is a well-known application (such as /usr/bin/firefox), but it
fails to do so if the default browser is a snap (e.g. the chromium
snap).
This is not a recent regression, it's not working on bionic either.
ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: evince 3.30.0-2
ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
Uname: Linux 4.18.0-7-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Sep 24 12:28:06 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-07-02 (813 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
SourcePackage: evince
UpgradeStatus: Upgraded to cosmic on 2018-09-14 (9 days ago)
modified.conffile..etc.apparmor.d.abstractions.evince: [modified]
mtime.conffile..etc.apparmor.d.abstractions.evince: 2018-09-24T11:35:41.904158
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1794064/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
