| 2018-10-04 12:16:12 |
Julian Andres Klode |
bug |
|
|
added bug |
| 2018-10-04 12:16:22 |
Julian Andres Klode |
description |
[Impact]
Frontends of dpkg such as apt and programs using the apt libraries currently acquire the dpkg "lock" lock file. They need to release it before running dpkg, as dpkg also acquires it. Therefore, there is a race condition: In case the application needs to run dpkg multiple times, another application could steal the lock from under it, and the running application would fail in the middle of the install, potentially rendering the system broken.
This fixes the problem by introducing an additional "lock-frontend" file that frontends do not release when calling dpkg. When dpkg is not called by a frontend using that file, it will try to acquire the frontend lock as well, preventing it from interfering with such frontends.
[Test case]
1. Hold lock, check that dpkg fails to run
2. Hold frontend lock, check that dpkg fails to run
3. Hold frontend lock, run dpkg with DPKG_FRONTEND_LOCKED set, it should succeed
[Regression potential]
This is an isolated change adding a new lock file. Therefore, regressions can only be expected in the form of that locking failing.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (this bug)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
[Impact]
Frontends of dpkg such as apt and programs using the apt libraries currently acquire the dpkg "lock" lock file. They need to release it before running dpkg, as dpkg also acquires it. Therefore, there is a race condition: In case the application needs to run dpkg multiple times, another application could steal the lock from under it, and the running application would fail in the middle of the install, potentially rendering the system broken.
This fixes the problem by introducing an additional "lock-frontend" file that frontends do not release when calling dpkg. When dpkg is not called by a frontend using that file, it will try to acquire the frontend lock as well, preventing it from interfering with such frontends.
[Test case]
1. Hold lock, check that dpkg fails to run
2. Hold frontend lock, check that dpkg fails to run
3. Hold frontend lock, run dpkg with DPKG_FRONTEND_LOCKED set, it should succeed
[Regression potential]
This is an isolated change adding a new lock file. Therefore, regressions can only be expected in the form of that locking failing.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
|
| 2018-10-04 12:18:05 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-10-04 12:18:05 |
Julian Andres Klode |
bug task added |
|
dpkg (Ubuntu Cosmic) |
|
| 2018-10-04 12:18:05 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-10-04 12:18:05 |
Julian Andres Klode |
bug task added |
|
dpkg (Ubuntu Bionic) |
|
| 2018-10-04 12:18:05 |
Julian Andres Klode |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-10-04 12:18:05 |
Julian Andres Klode |
bug task added |
|
dpkg (Ubuntu Xenial) |
|
| 2018-10-04 12:18:11 |
Julian Andres Klode |
dpkg (Ubuntu Cosmic): status |
New |
Fix Released |
|
| 2018-10-04 12:18:13 |
Julian Andres Klode |
dpkg (Ubuntu Bionic): status |
New |
Triaged |
|
| 2018-10-04 12:18:15 |
Julian Andres Klode |
dpkg (Ubuntu Xenial): status |
New |
Triaged |
|
| 2018-10-04 12:33:40 |
Francis Ginther |
tags |
|
id-5bae2d332620381fc09f9f9c |
|
| 2018-10-04 12:36:46 |
Julian Andres Klode |
dpkg (Ubuntu Bionic): status |
Triaged |
In Progress |
|
| 2018-10-04 12:36:48 |
Julian Andres Klode |
dpkg (Ubuntu Xenial): status |
Triaged |
In Progress |
|
| 2018-10-04 12:38:52 |
Julian Andres Klode |
description |
[Impact]
Frontends of dpkg such as apt and programs using the apt libraries currently acquire the dpkg "lock" lock file. They need to release it before running dpkg, as dpkg also acquires it. Therefore, there is a race condition: In case the application needs to run dpkg multiple times, another application could steal the lock from under it, and the running application would fail in the middle of the install, potentially rendering the system broken.
This fixes the problem by introducing an additional "lock-frontend" file that frontends do not release when calling dpkg. When dpkg is not called by a frontend using that file, it will try to acquire the frontend lock as well, preventing it from interfering with such frontends.
[Test case]
1. Hold lock, check that dpkg fails to run
2. Hold frontend lock, check that dpkg fails to run
3. Hold frontend lock, run dpkg with DPKG_FRONTEND_LOCKED set, it should succeed
[Regression potential]
This is an isolated change adding a new lock file. Therefore, regressions can only be expected in the form of that locking failing.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
[Impact]
Frontends of dpkg such as apt and programs using the apt libraries currently acquire the dpkg "lock" lock file. They need to release it before running dpkg, as dpkg also acquires it. Therefore, there is a race condition: In case the application needs to run dpkg multiple times, another application could steal the lock from under it, and the running application would fail in the middle of the install, potentially rendering the system broken.
This fixes the problem by introducing an additional "lock-frontend" file that frontends do not release when calling dpkg. When dpkg is not called by a frontend using that file, it will try to acquire the frontend lock as well, preventing it from interfering with such frontends.
[Test case]
1. Hold lock, check that dpkg fails to run
2. Hold frontend lock, check that dpkg fails to run
3. Hold frontend lock, run dpkg with DPKG_FRONTEND_LOCKED set, it should succeed
[Regression potential]
This is an isolated change adding a new lock file. Therefore, regressions can only be expected in the form of that locking failing.
[Other info]
This is part of a wider series of SRUs for frontend locking
- dpkg (bug 1796081)
- apt (bug 1781169)
- python-apt (bug 1795407)
- packagekit (bug 1795614)
- unattended-upgrades (bug 1789637)
- aptdaemon (no bug filed yet)
Further details about frontend locking can be found in https://lists.debian.org/debian-dpkg/2017/01/msg00044.html |
|
| 2018-10-17 22:30:52 |
Brian Murray |
dpkg (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-10-17 22:30:55 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-10-17 22:30:59 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-10-17 22:31:02 |
Brian Murray |
tags |
id-5bae2d332620381fc09f9f9c |
id-5bae2d332620381fc09f9f9c verification-needed verification-needed-xenial |
|
| 2018-10-17 22:33:12 |
Brian Murray |
dpkg (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-10-17 22:33:17 |
Brian Murray |
tags |
id-5bae2d332620381fc09f9f9c verification-needed verification-needed-xenial |
id-5bae2d332620381fc09f9f9c verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2018-10-18 14:21:01 |
Julian Andres Klode |
tags |
id-5bae2d332620381fc09f9f9c verification-needed verification-needed-bionic verification-needed-xenial |
id-5bae2d332620381fc09f9f9c verification-done-xenial verification-needed verification-needed-bionic |
|
| 2018-10-18 14:25:06 |
Julian Andres Klode |
tags |
id-5bae2d332620381fc09f9f9c verification-done-xenial verification-needed verification-needed-bionic |
id-5bae2d332620381fc09f9f9c verification-done verification-done-bionic verification-done-xenial |
|
| 2018-10-29 17:17:36 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-10-29 17:17:59 |
Launchpad Janitor |
dpkg (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-10-29 17:27:40 |
Launchpad Janitor |
dpkg (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-12-20 16:30:08 |
Jarno Suni |
bug |
|
|
added subscriber Jarno Suni |
