[debian-mysql] Bug#853008: Bug#853008: Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning

[Julian Gilbey]

On Mon, Jan 30, 2017 at 10:00:20AM +0000, Robie Basak wrote:
> On Mon, Jan 30, 2017 at 10:45:44AM +0100, Lars Tangvald wrote:
> > I think an ok short-term solution is to make a .postrm script for
> > mysql-server-core, and move the delete logic there with the check on
> > /usr/sbin/mysqld restored, for both MariaDB and MySQL. Then we don't need to
> > check on any specific packages, since we'd know any existing mysqld binary
> > doesn't belong to the package being purged. If the user has installed a
> > MariaDB, the deletion would be handled by mariadb-server-core being purged.
> 
> I follow why that would work now, thanks. I don't see any problem with
> doing this until we have better handling of /var/lib/mysql between
> variants. So +1, unless someone else raises something.

There is an issue with this: the postrm's in mysql-server-5.7 and
mariadb-server-10.1 do significantly more than just removing
/var/lib/mysql when purging - see my (now broken because of this!)
patches on bug#852495: they also do all of the debhelper fragments
which should only be performed on the purge of the final mysqld
instance.  These clearly don't belong in the server-core packages, and
it would be strange (and perhaps wrong) to shift them there.

So how about this, just a sketch at the moment rather than a full
patch?

* Leave the {mysql,mariadb}-server-core-* packages as they are.

* In the postrm of the {mysql,mariadb}-server-X.Y packages, have the
  following.  We do not do a full purge if /usr/sbin/mysqld is a link,
  as we know nothing about this setup; we only know /usr/sbin/mysqld
  being a regular executable.

# Do we (offer to) do a full purge, or is there another mysql server
# present?  This includes within it a check for "$1" = purge.
fullpurge=no
if [ "$1" = purge ]; then
  if [ ! \( -x /usr/sbin/mysqld -o -L /usr/sbin/mysqld \) ]; then
    fullpurge=yes
  elif [ -x /usr/sbin/mysqld ]; then
    # Does this /usr/sbin/mysqld belong to our server-core package?
    # If so, we can offer to do a full purge, otherwise we do not.

    # Use the DPKG_MAINTSCRIPT_PACKAGE to avoid hardcoding the package
    # name; this reduces the chances of future errors creeping in.
    # If we're being run outside of a dpkg run, then this is safe.
    package=${DPKG_MAINTSCRIPT_PACKAGE}
    corepackage=$(echo "$package" | sed -e 's/server-/server-core-/')
    daemonpackage=$(dpkg-query --search /usr/sbin/mysqld 2>/dev/null | grep ' /usr/sbin/mysqld$' | cut -d: -f1 || true)
    if [ "$corepackage" = "$daemonpackage" -a -n "$corepackage" ]; then
      fullpurge=yes
    fi
  fi
fi

Then in the rest of the postrm, check
  if [ $fullpurge = yes ]; then ...
instead of
  if [ "$1" = purge ]; then ...
when deciding whether to perform a purge action which should only be
done if this is the final mysqld-providing package.


I *think* this covers the cases, but I'm really not certain.  There is
a possibility that someone could be purging the old mysql-* packages
while installing a newer replacement, and I'm not sure how aptitude
would handle that one because of the somewhat complex
Breaks/Conflicts/Replaces settings in the various control files.  But
a sysadmin who tries to purge an old mysql-server-providing package
simultaneously to installing a new one is potentially asking for
things to be deleted, so I'm not overly concerned about this.  They
would still be asked about deleting data in this case, so there is a
safety net.  (But they could conceivably lose their apparmor settings
and so on.)

Best wishes,

   Julian