Meanwhile is there anything I can run manually to allow the running chromium process to access the old directory so when I close it it will be able to write state?
Chromium was refreshed from 266 to 274 back in 2018-04-03T11:21:31-03:00 and since I didn’t noticed that right away I still have 266 running. dmesg shows a lot of denied access to the config directory:
[216657.271824] audit: type=1400 audit(1523034491.823:133728): apparmor=“DENIED” operation=“open” profile=“snap.chromium.chromium” name="/home/tdaitx/snap/chromium/266/.config/chromium/Default/Cookies-journal" pid=17477 comm=“TaskSchedulerBa” requested_mask=“wc” denied_mask=“wc” fsuid=1000 ouid=1000
UPDATE:
As a reference for anyone else running into this, I “fixed” the issue by editing chromium’s profile:
--- /var/lib/snapd/apparmor/profiles/snap.chromium.chromium.orig 2018-04-06 14:38:03.993227496 -0300
+++ /var/lib/snapd/apparmor/profiles/snap.chromium.chromium 2018-04-06 14:33:21.461700026 -0300
@@ -335,6 +335,7 @@
owner @{HOME}/snap/@{SNAP_NAME}/** mrkix,
# Writable home area for this version.
+ owner @{HOME}/snap/@{SNAP_NAME}/266/** wl,
owner @{HOME}/snap/@{SNAP_NAME}/@{SNAP_REVISION}/** wl,
owner @{HOME}/snap/@{SNAP_NAME}/common/** wl,
@@ -343,6 +344,7 @@
/var/snap/@{SNAP_NAME}/** mrkix,
# Writable system area only for this version
+ /var/snap/@{SNAP_NAME}/266/** wl,
/var/snap/@{SNAP_NAME}/@{SNAP_REVISION}/** wl,
/var/snap/@{SNAP_NAME}/common/** wl,
Then I ran
$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.chromium.chromium
Please not that this is just a hack in order to be able to close the browser without losing state.
Before restarting chromium I also replaced the 274 directory with 266 (with a backup of each just in case). After the restart it seems like chromium’s apparmor profile was re-generated and my changes to it were gone.
Please, do not try this if you don’t understand what I am talking about.