Can you provide details about that crash? Which version of Ubuntu, which channel of the chromium snap, what desktop environment, does it crash right away at startup or are there a specific set of actions/pages that trigger the crash?
Technically, chromium is in universe, not in main (see this documentation). The deb packages won’t disappear, but they are becoming transitional packages that install the snap when installing/upgrading.
I’m not sure about Pop!_OS, but I’m pretty sure Ubuntu Mate supports snaps as first-class citizens.
Once the transition is complete there won’t be a PPA maintained by the Ubuntu desktop team, because one of the goals of this transition is to relieve some of the packaging/maintenance work.
@oSoMoN hi, the deb package source ~/.chromium-browser.init if available in order to pass additional chromium flags on startup without having to modify .desktop launcher. Could chromium snap introduce similar functionality? Of course ~/.chromium-browser.init should be sourced from snap specific home (inside ~/snap) in that case.
fails o my system (Ubuntu 19.04 + KDE session + kwallet) saying that nothing provides org.freedesktop.Secret.Service and chromium fallbacks to plain backend (losing my passwords). When I add --password-store=kwallet to desktop file command it works correctly.
So current approach for backed detection is broken in my case (maybe in general for kwallet). Maybe it’s possible to test also kwallet equivalent of that command however I don’t know what i should be
You are right, it appears the gtk-common-themes snap in the candidate channel fixes the theming problem. Well spotted!
I am now trying to bisect what change fixed the problem, and I will talk to the maintainers to have it promoted to stable.
@oSoMoN I noticed that kwallet detection still fails if kwalllet isn’t running before chromium starts. In that case the test call is blocked by apparmor: dbus-daemon[1464]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/modules/kwalletd5" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.kde.kwalletd5" pid=2837 label="snap.chromium.chromium"
If I pass --password-store=kwallet then chromium triggers kwallet start automatically. Is it something fixable or should I force running kwallet before starting chromium?
On a side note I also see quite similar blocked call for bluez: audit[1166]: USER_AVC pid=1166 uid=104 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=2719 label="snap.chromium.chromium"
I don’t use bluetooth so I don’t know what are the consequences of above.
it doesn’t seem to be security sensitive. Is it possible to allow this action by adding something like: owner @{PROC}/@{pid}/clear_refs w, to chromium apparmor profile?
You are right, and the problem is similar for org.freedesktop.secrets if gnome-keyring-daemon is not already running.
I would have expected D-Bus activation to work in this context.
However, in the context of a normal KDE session I would expect kwallet to be running already (and same for gnome-keyring-daemon in a GNOME session). Is this not a safe assumption?
It depends on system settings. I didn’t added kwallet to autostart applications. I also have it set to exit on idle. That means on my system it’s very likely that it won’t be running at the time chromium is launched. I can change it if there is no other workaround however I believe there will be more people hitting this issue and complaining about it.
My concern isn’t about it being harmful but about endless syslog spam. I’m heavy apparmor user and I have set desktop notifications for all denials so this isn’t ok for me. We can forget about bluez but please either allow /proc/PID/clear_refs or deny it but not leave it as is.
I see, that’s annoying indeed. As I wrote in an earlier comment, I would have expected D-Bus activation to work in this context. @jdstrand: can you shed some light on this problem? The chromium launcher script talks to D-Bus (session bus) to guess whether a password manager daemon is available for the browser to talk to, but it appears activation doesn’t work if said daemon is not yet running. Is that expected? Is there an obvious mistake in that launcher script?
