#!/bin/sh
# postinst for the privacyfence .deb. Keep this minimal and idempotent (safe to re-run on
# upgrade) -- see the now-removed docs/linux-local-deb-packaging-plan.md Phase 2/P3.3.
set -e

case "$1" in
    configure)
        # Best-effort icon-cache refresh so /usr/share/icons/hicolor/*/apps/privacyfence.png
        # (installed by debian/install) is picked up immediately rather than only after the next
        # unrelated cache rebuild. Neither tool is guaranteed present on every system (e.g. a
        # minimal server install), and a failure here must never block the package install --
        # this is cosmetic (icon lookup by name from resources/linux/privacyfence.desktop),
        # nothing functional depends on it.
        if command -v gtk-update-icon-cache >/dev/null 2>&1; then
            gtk-update-icon-cache -f -t /usr/share/icons/hicolor >/dev/null 2>&1 || true
        fi
        ;;
    abort-upgrade|abort-remove|abort-deconfigure)
        ;;
    *)
        ;;
esac

# Nothing in this block starts the daemon. The XDG autostart entry
# (/etc/xdg/autostart/privacyfence.desktop, installed above) only fires at the *next* graphical
# login -- correct DMG-parity behavior (the DMG doesn't launch the app immediately after a
# drag-install either). postinst runs as root, which can neither correctly determine the
# installing user's desktop session nor safely start a per-user daemon on their behalf --
# see the now-removed docs/linux-local-deb-packaging-plan.md P3.3.
#
# That is no longer the whole install, though: the privilege-separation block right below hands
# startup to a *system* unit instead, which root can start outright, and does. Since ADR 0003
# decision 5 that is unconditional: this package's `configure` step ends with the daemon already
# running under privacyfence-daemon.service, not merely armed to start at the next login, or it
# ends by failing.

# ADR 0003 decisions 1, 3 and 5 (#428 D1, 4.1, is where this hook came from): separate this
# install here, as part of configuring the package, on every install and upgrade (dpkg calls this
# same `configure` case for both -- $2 is the old version on an upgrade, empty on a fresh install,
# and neither changes what to do). postinst already runs as root, which is exactly what `enable`
# needs, and the "postinst can't safely act on a user's behalf" reasoning above was about the
# *daemon*, not this.
#
# Two calls, because decision 3's two halves have two different failure policies:
#
#   1. The machine half -- create the privacyfence system account, move the data directory, write
#      the marker, install and start privacyfence-daemon.service. None of that needs to know which
#      human this install is for, so it runs unconditionally and *without* `|| true`. That missing
#      `|| true` is decision 5: under decision 1 an install that could not separate itself is not
#      a less-hardened PrivacyFence, it is one whose central claim ("the agent cannot approve its
#      own request") does not hold, so this is not the ancillary step a postinst is supposed to
#      shrug off. A failure here fails the package install, loudly, and leaves dpkg with a
#      half-configured package a human has to look at -- which is the honest outcome, rather than
#      an installed-looking package that is not what it says it is.
#
#      `--machine-only` rather than a plain `enable` on purpose: $SUDO_USER is sitting right there
#      in this script's environment, and a plain `enable` would pick it up and do the group add on
#      this call -- putting the one step that is allowed to defer inside the one call that is not.
#
#   2. The per-user half -- add the installing human to the privacyfence group and migrate
#      whatever they already had under ~/.privacyfence. This one genuinely does need to know who
#      they are, and $SUDO_USER is the only thing here that can say: it names a real, non-root
#      account when this .deb was installed via `sudo apt install`/`sudo dpkg -i`, and nothing
#      when root installed it directly or an unattended upgrade did. So it stays conditional, and
#      it keeps both `--auto` (never die(); log why and exit 0 -- see the script's own --auto
#      handling) and a `|| true` for the paths --auto can't reach from inside. Deferring this half
#      is a supported state, not a failure: `status` reports it as PENDING USER, the companion app
#      closes it at the first real login session, and `sudo privacyfence-privilege-separation
#      enable --for-user <name>` closes it by hand.
#
# So an unattended upgrade with no session behind it still succeeds *and* still ends up separated,
# with the group membership pending -- which is the case the old `|| true` was protecting, now
# handled rather than excused.
#
# Idempotent either way: `enable` refreshes rather than fails on an already-separated install, and
# re-running the machine half against one whose per-user half is already closed keeps the owner
# recorded in the marker rather than clearing it (see write_marker in the script).
#
# On an upgrade of an already-separated install, the machine half is also what starts the daemon
# back up: debian/prerm's `upgrade` case stops privacyfence-daemon.service before dpkg unpacks
# this version's files over /opt/privacyfence, so the running PyInstaller onedir process is never
# reading a directory being swapped out from under it. `enable` (inside cmd_enable's
# install_services) is what starts it again, now against the new files.
if [ "$1" = "configure" ] && [ -x /usr/sbin/privacyfence-privilege-separation ]; then
    /usr/sbin/privacyfence-privilege-separation enable --machine-only

    if [ -n "${SUDO_USER:-}" ] && [ "$SUDO_USER" != "root" ]; then
        /usr/sbin/privacyfence-privilege-separation enable --auto --for-user "$SUDO_USER" || true
    fi
fi

exit 0
