Call for testing: chromium-browser deb to snap transition


@Reynolds5 this issue is fixed in the candidate channel. Would you mind testing it and reporting back?

snap refresh chromium --candidate


Snapped Chromium still has theming issues in Ubuntu 19.10 (and before).
The bug have been reported since last year:


@oSoMoN works, thank you very much.


Excellent, thanks for the confirmation. I have now promoted the snap from the candidate channel to stable, so you can switch channels again:

snap refresh chromium --stable


The issue is solved by updating the gtk-common-themes snap to candidate channel.


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.


@oSoMoN there is one more thing - from time to time chromium tries to write into /proc/PID/clear_refs which is blocked by apparmor.

After reading various sources:

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?

D-Bus activation for snaps

The other denials (bluez and /proc/PID/clear_refs) should be harmless, so you can safely ignore them.


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.


Regarding password-store backends, for some people ability to pass persistent chromium flags would help


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?


@oSoMoN I’ve seen this problem where the session service isn’t started by D-Bus activation because it’s being activated by a confined process and Apparmor (or maybe systemd I don’t remember) isn’t sure what confinement the service launched will be under and so it doesn’t get activated. See

The fix for that was to add AssumedAppArmorLabel=unconfined to the service file for netplan, perhaps kwallet needs to do the same thing? I’m assuming kwallet runs unconfined


Yes, I confirmed that adding AssumedAppArmorLabel=unconfined to kwallet service make dbus activation works again

Considering that almost all services don’t have Apparmor profile thus run unconfined then we can conclude that dbus activation is generally broken for snaps. Moreover patching every service, either upstream or in every distro separately sound like herculean if not impossible task. Maybe you should ask dbus upstream to revert or fix it some other way?


And I can confirm that AssumedAppArmorLabel=unconfined fixes D-Bus activation of both gnome-keyring-daemon and kwalletd5 from within a snap.


I’ve started another topic to discuss broken D-Bus activation. Hopefully there exists a solution that doesn’t involve patching every single D-Bus service file out there.


For some reason my chromium profile does not import from .config/chromium when I start the snap chromium. How does one go about importing their profile manually?


well, it looks like I was able to restore access to saved passwords via snap connect chromium:password-manager-service


Yes, the connection should have happened automatically, sorry for the inconvenience (this is being tracked by bug #1849160).

As for the profile import, it happens only the first time the chromium snap is run, and it basically copies the contents of $HOME/.config/chromium to $SNAP_USER_DATA/.config/chromium.