#!/bin/sh
# prerm for the privacyfence .deb. There is no system-wide daemon instance for this package to
# stop on an unseparated install -- the daemon only ever runs as a per-user background process,
# started either by the XDG autostart entry this package installs
# (/etc/xdg/autostart/privacyfence.desktop) or manually via `privacyfence-app` -- and prerm runs as
# root with no reliable way to reach into a user's desktop session to stop it. See the now-removed
# docs/linux-local-deb-packaging-plan.md Phase 2/P3.3 for the same reasoning applied to postinst not
# starting it either.
#
# #428 D1 (4.1) changed this, and ADR 0003 decision 5 made it unconditional: postinst's machine
# half (`enable --machine-only`) turns every install into a separated one, with a real system-wide
# daemon (privacyfence-daemon.service, running as the privacyfence
# system account) and the user's migrated ~/.privacyfence -- including live connector OAuth tokens
# and the audit log -- moved to /var/lib/privacyfence, owned by that account. Nothing previously
# undid that on removal: `apt remove` deleted /usr/sbin/privacyfence-privilege-separation (the only
# tool that can reverse it) along with the rest of /opt/privacyfence, stranding that data under a
# 0700 directory the user can no longer read and a stale systemd unit pointing at a binary that no
# longer exists.
#
# So a real `remove` -- not `upgrade`/`deconfigure`, which must leave a separated install *enabled*
# (just briefly stopped on `upgrade`, see below) -- now runs `disable` first, while the tool that
# can still exists, undoing exactly what the postinst did: stops and removes the system unit,
# and moves the data (including those OAuth tokens) back to ~/.privacyfence. Best-effort
# (`|| true`): this must never fail the removal, and an install that was never separated in the
# first place -- a pre-4.1 one, or one `disable` was already run on -- has no marker for
# `disable` to find, which is exactly the ordinary case it exits non-zero for.
#
# Per P2.2: this script must never reach into a user's $HOME on its own (that's where
# ~/.privacyfence/ -- config, credentials, audit log -- lives, and it is not package-owned;
# removing this package must leave it untouched). `disable` restoring a separated install's data
# back into $HOME is the one deliberate exception -- it is returning data to the user, not deleting
# or overwriting anything they own, and only ever runs against a directory this same package's
# postinst moved out of $HOME in the first place. Any other future edit adding cleanup logic here
# must keep the original invariant.
#
# `upgrade` stops the system unit for the same reason `remove` above undoes separation entirely:
# a separated install's daemon (privacyfence-daemon.service, running as the privacyfence system
# account) runs the packaged PyInstaller onedir build straight out of /opt/privacyfence, and dpkg
# unpacks the new version's files over that same directory *before* postinst runs -- a lazily
# loaded shared library can vanish out from under the still-running old process mid-upgrade and
# crash it. Stopping first avoids that window; postinst's machine half, which already runs on
# every upgrade (see its own comment), starts the unit again once the new files are in place, so
# this never leaves the daemon down. Best-effort and harmless on an unseparated install, where the
# unit was never installed: `systemctl stop` on an unknown unit just fails, and `|| true` absorbs
# it, same as `disable --now` already does elsewhere in this flow.
set -e

case "$1" in
    remove)
        if [ -x /usr/sbin/privacyfence-privilege-separation ]; then
            /usr/sbin/privacyfence-privilege-separation disable || true
        fi
        ;;
    upgrade)
        if command -v systemctl >/dev/null 2>&1; then
            systemctl stop privacyfence-daemon.service >/dev/null 2>&1 || true
        fi
        ;;
    deconfigure)
        ;;
    failed-upgrade)
        ;;
    *)
        ;;
esac

exit 0
