[RFC/PATCH] dpkg frontend locking

[Julian Andres Klode <jak@debian.org>]

Hi everyone,

I talked with guillem about this idea on IRC, but I decided to
write this down in an email for further discussion.

Currently, APT and other dpkg frontends have to acquire the dpkg
database lock at the start of their process and then have to release
the dlock before invoking dpkg and re-acquire it afterwards. 

This leads to a race condition where another process could acquire
the database lock while another frontend is about to start a new
dpkg process.

The proposed fix for that is simple: Introduce a new lock called
the frontend lock.

Frontends will acquire both the frontend lock and the database
lock (in that order) and for invoking dpkg only release the
database lock while keeping the frontend lock.

Dpkg will acquire both locks, unless DPKG_FRONTEND_LOCKED is
set, in which case only the database lock is acquired and the
frontend lock is ignored.

Compatibility matrix:

Assuming two frontends (f1 running, f2 not) and a dpkg with the old
and new behavior each, it looks like this.

   f1	f2	dpkg	situation
1. old	old	old	Same as now (easy race)
2. old	old	new	Same as now (easy race)
3. old	new	old	still a race as f1 has no frontend lock
4. old	new	new	still a race
5. new	old	old	still a race possible.
6. new  old     new	no race. dpkg will refuse to run by f2
                        because it will try to acquire the fe lock
                        hold by f1.
7. new  new     old     the frontends can't run at the same time,
                        but dpkg could be run manually
8. new	new	new	like 7, but without the manual dpkg backdoor


Branches:

apt: git fetch https://github.com/julian-klode/apt bugfix/big-lock
-> diff: https://github.com/Debian/apt/compare/master...julian-klode:bugfix/big-lock?expand=1

dpkg: git fetch https://github.com/julian-klode/dpkg/compare/master pu/frontend-lock 
-> diff: https://github.com/julian-klode/dpkg/compare/master...julian-klode:pu/frontend-lock

It's also trivial to add to python-apt, meaning that apt and the
whole python-apt ecosystem (including unattended-upgrades) will
be safe against interference from other package manager frontends.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
                  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.