| 2016-08-24 22:08:21 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2016-08-24 22:09:33 |
Jamie Strandboge |
description |
In testing 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.
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? |
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? |
|
| 2016-09-30 11:59:38 |
Jamie Strandboge |
snappy: status |
New |
Confirmed |
|
| 2016-11-29 17:05:52 |
Michael Vogt |
snappy: status |
Confirmed |
Incomplete |
|
| 2017-01-29 04:17:48 |
Launchpad Janitor |
snappy: status |
Incomplete |
Expired |
|
| 2017-12-18 13:52:28 |
Jamie Strandboge |
affects |
snappy |
snapd |
|
| 2017-12-18 13:52:28 |
Jamie Strandboge |
snapd: status |
Expired |
Confirmed |
|
| 2018-01-02 09:13:44 |
Michael Vogt |
snapd: status |
Confirmed |
Triaged |
|
| 2018-01-02 09:13:45 |
Michael Vogt |
snapd: importance |
Undecided |
Medium |
|
| 2018-07-19 12:09:50 |
Zygmunt Krynicki |
snapd: assignee |
|
Zygmunt Krynicki (zyga) |
|
| 2018-08-16 10:00:12 |
Kai Kasurinen |
bug |
|
|
added subscriber Kai Kasurinen |
| 2018-12-07 17:00:21 |
Zygmunt Krynicki |
snapd: status |
Triaged |
In Progress |
|
| 2019-02-14 11:54:20 |
Zygmunt Krynicki |
snapd: milestone |
|
2.39 |
|
| 2019-09-21 11:43:08 |
Efthimios Chaskaris |
bug |
|
|
added subscriber Efthimios Chaskaris |
| 2019-10-03 23:46:09 |
Ben |
bug |
|
|
added subscriber Ben |
| 2019-10-11 18:58:34 |
Paul White |
bug |
|
|
added subscriber Paul White |
| 2019-10-29 19:40:08 |
Zygmunt Krynicki |
snapd: milestone |
2.39 |
|
|
| 2020-01-28 07:50:17 |
Haw Loeung |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2020-04-05 02:16:00 |
Avamander |
bug task added |
|
chromium-browser (Ubuntu) |
|
| 2020-04-07 12:11:06 |
Launchpad Janitor |
chromium-browser (Ubuntu): status |
New |
Confirmed |
|
| 2020-04-09 07:40:31 |
Ernst Sjöstrand |
bug |
|
|
added subscriber Ernst Sjöstrand |
| 2020-04-11 11:18:34 |
Haw Loeung |
bug |
|
|
added subscriber Haw Loeung |
| 2020-04-30 06:58:38 |
Ernst Sjöstrand |
removed subscriber Ernst Sjöstrand |
|
|
|
| 2020-06-17 17:20:01 |
Olivier Tilloy |
chromium-browser (Ubuntu): status |
Confirmed |
In Progress |
|
| 2020-06-17 17:20:05 |
Olivier Tilloy |
chromium-browser (Ubuntu): assignee |
|
Olivier Tilloy (osomon) |
|
| 2020-06-17 17:20:07 |
Olivier Tilloy |
chromium-browser (Ubuntu): importance |
Undecided |
High |
|
| 2020-06-21 20:01:08 |
Alexander Browne |
bug |
|
|
added subscriber Alexander Browne |
| 2020-10-07 13:25:34 |
Olivier Tilloy |
chromium-browser (Ubuntu): status |
In Progress |
Fix Released |
|
| 2021-02-05 14:13:04 |
MDE |
bug |
|
|
added subscriber MDE |
| 2021-03-25 15:54:05 |
Olivier Tilloy |
bug task deleted |
chromium-browser (Ubuntu) |
|
|
| 2021-06-29 19:19:29 |
Brett Keller |
bug |
|
|
added subscriber Brett Keller |
| 2021-10-13 20:33:05 |
johannesjo |
bug |
|
|
added subscriber johannesjo |
| 2022-12-28 13:46:11 |
Mantas Kriaučiūnas |
bug |
|
|
added subscriber Mantas Kriaučiūnas |
| 2022-12-28 13:46:18 |
Mantas Kriaučiūnas |
bug |
|
|
added subscriber Baltix GNU/Linux activists |
| 2022-12-28 13:46:30 |
Mantas Kriaučiūnas |
bug |
|
|
added subscriber Aldas |
