@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 --stableThe 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.
1 Like
@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:
http://man7.org/linux/man-pages/man5/proc.5.html
https://www.cnblogs.com/cobbliu/p/5745632.html#sec-2
https://lwn.net/Articles/637190/
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?
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 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1749000
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
2 Likes
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 https://cgit.freedesktop.org/dbus/dbus/commit/?id=dc25979eb or fix it some other way?
1 Like
And I can confirm that AssumedAppArmorLabel=unconfined fixes D-Bus activation of both gnome-keyring-daemon and kwalletd5 from within a snap.
2 Likes
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.
It seems like the Chromium snap takes longer to start than the .deb and support for desktop “app” generation through .desktop files remains completely broken.
Reference: How to expose desktop files created by snaps to the DE?
If you go to “More Tools… Create Shortcut / Open In New Window”, you should end up with a new “app” that you can find in the launcher and will have it’s own icon and handling when added to the dock.
The flow to create a new “app” finishes without error in the Snap now, yet no app is found in the launcher and the new app is grouped with the original Chromium app in
the dock.
I tried to workaround this issue by installing the “.deb” instead of the “.snap”, but this did
not work. The .deb file redirects to install the snap instead.
This is very frustrating. Now to get Chromium working again on Ubuntu I either have to track down a non-snap / non-deb version or switch to a Linux distribution with non-broken Chromium package.
1 Like
The snap packaging breaks the “Open In Firefox” extension:
https://github.com/andy-portmen/native-client/issues/79
The issue is that the snap package does not use the standard ~/.config" directory to store files. The “native client” installer for the extension installs files into ~/.config/chromium, but this fails because it’s not the directory used by the browser.