Add support for dpkg frontend lock

The dpkg frontend lock is a lock dpkg tries to acquire
except if the frontend already acquires it.

This fixes a race condition in the install command where the
dpkg lock is not held for a short period of time between
different dpkg invocations.

For this reason we also define an environment variable
DPKG_FRONTEND_LOCKED for dpkg invocations so dpkg knows
not to try to acquire the frontend lock because it's held
by a parent process.

We can set DPKG_FRONTEND_LOCKED only if the frontend lock
really is held; that is, if our lock count is greater than 0
- otherwise an apt client not using the LockInner family of
functions would run dpkg without the frontend lock set, but
with DPKG_FRONTEND_LOCKED set. Such a process has a weaker
guarantee: Because dpkg would not lock the frontend lock
either, the process is prone to the existing races, and,
more importantly, so is a new style process.

Closes: #869546

[fixups: fix error messages, add public IsLocked() method, and
 make {Un,}LockInner return an error on !debSystem]

(cherry picked from commit c2c8b4787b0882234ba2772ec7513afbf97b563a)
LP: #1781169
(cherry picked from commit 6c0c94ed32b8e679b14b0f89b51c1c336dc0ab9c)

1 files changed, 12 insertions, 0 deletions

diff --git a/apt-pkg/pkgsystem.h b/apt-pkg/pkgsystem.h
index 55bdeec70..8c7c300fb 100644
--- a/apt-pkg/pkgsystem.h
+++ b/apt-pkg/pkgsystem.h
@@ -116,6 +116,18 @@ class pkgSystem
 
    pkgSystem(char const * const Label, pkgVersioningSystem * const VS);
    virtual ~pkgSystem();
+
+
+   /* companions to Lock()/UnLock
+    *
+    * These functions can be called prior to calling dpkg to release an inner
+    * lock without releasing the overall outer lock, so that dpkg can run
+    * correctly but no other APT instance can acquire the system lock.
+    */
+   bool LockInner();
+   bool UnLockInner(bool NoErrors = false);
+   /// checks if the system is currently locked
+   bool IsLocked();
    private:
    void * const d;
 };