From 70a75864718f17ebc7714f6b9ecb3e3bc64533a6 Mon Sep 17 00:00:00 2001 From: Bendik Aagaard Lynghaug Date: Tue, 4 Aug 2026 20:36:54 +0200 Subject: [PATCH] Drop sudo from the deploy workflow - NoNewPrivileges blocks it outright sudo needs setuid escalation, which the runner's own unit disables entirely via NoNewPrivileges=yes (unconditionally, independent of any sudoers config - the earlier sudoers.d/deploy-runner grant was never going to work). Caddy reload already works via the runner's existing docker group membership; the service restart now goes through plain systemctl (talks to PID1 over D-Bus, no escalation needed), authorized by a new polkit rule scoped to deploy-runner + app@*.service. --- .gitea/workflows/deploy.yml | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/.gitea/workflows/deploy.yml b/.gitea/workflows/deploy.yml index 3c95536..67b1d5b 100644 --- a/.gitea/workflows/deploy.yml +++ b/.gitea/workflows/deploy.yml @@ -74,9 +74,17 @@ jobs: LEPTOS_SITE_ADDR=0.0.0.0:3010 EOF + # No sudo: the runner's own unit sets NoNewPrivileges=yes, which + # blocks setuid escalation outright (sudo can't work at all under + # it, regardless of sudoers config) - systemctl talks to PID1 over + # D-Bus instead, authorized by a polkit rule scoped to deploy-runner + # + this unit pattern (see /etc/polkit-1/rules.d/10-deploy-runner.rules + # on the host). - name: Restart service - run: sudo systemctl restart app@uhhm-portal.service + run: systemctl restart app@uhhm-portal.service + # No sudo here either - the runner is already in the `docker` group, + # so it can talk to the Docker socket directly. - name: Update Caddy routing run: | cat > /etc/caddy/services.d/uhhm-portal.caddy <<'EOF' @@ -85,4 +93,4 @@ jobs: log { output file /var/log/caddy/www.log } } EOF - sudo docker exec caddy caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile + docker exec caddy caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile