ZacharyZhang-NY/omarchycn
4
5
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases 5 Wiki Activity

Remove privileged files left behind by retired Omarchy installers

Browse Source 
Three installers that no longer exist each left a root-owned file on
disk, and nothing in Omarchy has ever removed any of them.

/etc/sudoers.d/first-run granted the installing account passwordless
sudo for the rest of the first boot, unrestricted /usr/bin/systemctl
included from 2025-10-14 on. omarchy-first-run clears its first-run.mode
guard before eight set -e steps and only deletes the grant after them,
so any failure in between strands it with nothing left to retry.

/etc/sudoers.d/tsui named whatever $(which tsui) resolved to for the
installing user, normally a binary under their own home that the vendor
script had just written without sudo.

/etc/systemd/system/omarchy-plymouth-shutdown.service ran an ExecStop
under the installing user's home as uid 0 on every shutdown.

Each file is judged against what the installer that wrote it actually
produced. The first-run grant was rewritten eight times and only the
last four carry both Cmnd_Alias lines, so rather than key on those, every
active line must be one the installer emitted and one of them must be
its own self-cleanup. The shutdown unit is disabled but never stopped:
stopping it is what would run the ExecStop being taken away.

Generalize the migrations.md exception, which framed itself around pre-4
layout transitions and so did not cover installers retired on their own.
This commit is contained in:
acrogenesis
2026-08-29 19:22:44 -06:00
parent cd519283fe
commit 96ed473ce1
3 changed files with 723 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agents/skills/migrations.md
+11 -10
View File
@@ -166,13 +166,14 @@ Omarchy 4.0 is upgraded through `bin/omarchy-upgrade-to-quattro`, not through th
normal migration runner. Do not add compatibility migrations for old installer
layouts; put pre-4 package-layout transition work in the upgrade command instead.
Clearing a pre-4 layout that is a security defect is the exception, and belongs in
a migration. The upgrade command only runs on a machine still making the 3 to 4
crossing, so anything put there never reaches an install that crossed already —
and a file an old installer wrote with a vulnerability in it is still sitting on
those machines. The upgrade command finishes by running `omarchy-migrate`
(`run_post_upgrade_migrations`), so one migration reaches both populations;
a copy in the upgrade command would only be a second copy of the same predicate
to keep correct. Such a migration must name the defect it clears and match the
state the old installer actually produced, so a file the user wrote themselves is
left alone.
Clearing a privileged file that a retired installer left on disk is the exception,
and belongs in a migration whether or not that installer was part of a package
layout transition. The upgrade command only runs on a machine still making the 3
to 4 crossing, so anything put there never reaches an install that crossed
already, and it never runs at all for an installer that was retired on its own —
while the file the installer wrote is still sitting on those machines. The upgrade
command finishes by running `omarchy-migrate` (`run_post_upgrade_migrations`), so
one migration reaches every population; a copy in the upgrade command would only
be a second copy of the same predicate to keep correct. Such a migration must name
the defect it clears and match what the old installer actually produced, so a file
an administrator wrote themselves is left alone.