** Changed in: chromium-browser (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1616650
Title:
snap refresh while command is running may cause issues
Status in snapd:
In Progress
Status in chromium-browser package in Ubuntu:
Fix Released
Bug description:
In testing a desktop snap that saves state in $HOME on close, I
noticed that if I snap refresh the snap while the command is running
that it will try to save its state to the previous snap version's data
directory. For the snap I was testing (a browser), this resulted in a
very poor user experience (the browser on restart complained about an
improper shutdown).
What is happening is that:
1. on launch the snap's HOME is set to SNAP_USER_DATA, which is something
like /home/user/snap/foo/x1. The security policy correctly allows writes to
SNAP_USER_DATA
2. on snap refresh to 'x2', the security policy for the snap is updated for
the running process such that /home/user/snap/foo/x1 is readonly and
/home/user/snap/foo/x2 is read/write
3. the command in '1's environment is not changed and HOME (as well as
SNAP_USER_DATA and SNAP_DATA) are all still using 'x1' in the path
4. the command tries to shutdown gracefully and save state to the 'x1' HOME
and security policy blocks it
Snappy's design for rollbacks relies on the previous SNAP_DATA and
SNAP_USER_DATA directories not being writable and IMHO we should not
change the policy to make other snap version's data dirs writable.
The design of the snappy state engine ensures (among other things)
that there is only ever one security policy in place for the snap. In
snappy 15.04 this problem was (intentionally) avoided because we used
snap security policy that was versioned such that the new policy would
not apply until the next app invocation.
Gustavo and Zygmunt, you both advocated strongly for only one version
of the policy on disk and loaded in the kernel and I recall bringing
up this type of bug as a counter-argument, and if IIRC for daemons we
said that snapd could simply restart them (makes perfect sense). Have
you thought of the mechanism for restarting non-daemons?
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1616650/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
