Seed Chromium's first-run preferences with a mode the browser can read

[shaynhornik]

Problem

migrations/1787691200.sh (from #8203) writes the Chromium first-run seed with sudo mkdir -p and echo | sudo tee, with no mode. omarchy-migrate runs migrations as the user under the caller's umask, and sudo keeps it: sudoers applies the union of the caller's umask and its own 0022. Under umask 077 the seed lands as -rw------- root root inside a 0700 directory. Chromium, running as the user, cannot read it, the terms-of-service dialog the migration exists to skip comes back, and the migration exits 0 and records itself done. Under umask 027 the file is 0640, unreadable to anyone outside group root, which is the same failure. A second user's run cannot repair it either: their cat fails, and the rewrite produces the same modes.

The repo already treats this as a house rule. migrations/1786278735.sh sets explicit modes for exactly this reason ("so a restrictive user umask cannot leave the root-owned drop-in unreadable to the unprivileged ssh client"), and the FIDO2 migration from #7904 repairs the same sudo mkdir -p umask union.

Change

Create the directory with install -d -m 755 and the seed with install -m 644 -T /dev/stdin, following the keepalive migration and the upgrade command's own install -d -m 0755 for this directory. The existing content check keeps the migration idempotent, and it now doubles as repair: on a machine the old write already hit, the user's cat fails, the seed is rewritten readable, and install -d puts the directory back to 755. The 3.x upgrade path writes the same seed with a bare tee and then runs omarchy-migrate, so this migration repairs that copy as well.

Verification

• New test/shell.d/chromium-first-run-seed-migration-test.sh, in the retargeted-copy style of the sshd hardening and FIDO2 migration tests: a sudo stub that logs and execs, the one path literal rewritten to a scratch tree (asserted to occur exactly once), every scenario under umask 077. It checks seed content and modes on a fresh machine (644 file, 755 directory), no privilege calls on a rerun, and repair of a root-only 0700/000 leftover. Passes locally, 3 ok.
• The same harness against the migration as shipped on quattro produces 700 and 600, so the test fails without the fix.
• migrate-wrapper, migrate-notify, sshd-hardening-migration, and security-fido2-migration tests still pass. The eight ./test/shell files that fail on this machine fail identically on pristine quattro (host assumptions: a sibling omarchy-pkgs checkout, rg, hardware tools) and are unrelated.

Written with Claude Code; I reviewed the change and ran the tests above locally.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FTqr6ZjXfNthXT719ag7Qc

[shaynhornik]

Noting #9070, which retires this seed altogether in favour of a per-user EULA Accepted sentinel. This is the narrow repair for the migration as it ships today, for machines on a hardened umask that get the dialog back while #9070 is pending. The seed bytes are unchanged, so #9070's hash-gated removal still matches what this writes. Happy to close this if #9070 is close to landing.

[omarchybot]

Reviewed at 43a2b6c, against quattro at f45461a. Nothing found that needs changing.

Reproduced on a disposable Omarchy worker with real sudo. Under umask 077, sudo kept 0077. The migration as it ships on quattro wrote /usr/lib/chromium/initial_preferences as 600 root:root, and the user could not read it. This head, run over that leftover, rewrote it as 644 with the directory at 755, and the user could read it again. A rerun made no sudo calls. With /usr/lib/chromium missing, it created the directory at 755 and the seed at 644.

Tests on the worker. chromium-first-run-seed-migration-test.sh passes 3 of 3. With the migration reverted to quattro's, it fails with mode 600. ./test/cli, migrate-wrapper-test.sh, migrate-notify-test.sh and unowned-system-paths-test.sh all pass. The browser's dialog itself was not observed: what was checked is that the seed is unreadable to the user, which leaves Chromium in the same state as having no seed.

Second opinion (Codex Medium). It agreed the bug is real and the fix proportionate, though its independence is not guaranteed. It found no defect in the migration. It suggested making the test stricter: check that the destination was actually rewritten before running anything, and cover a seed whose content already matches but cannot be read. Neither changes what reaches a user. The real-sudo run above covers the matching-but-unreadable case. Its other point is real but outside this pull request: install/config/theme-system.sh and bin/omarchy-upgrade-to-quattro still write the seed without a mode. The upgrade path runs this migration afterwards, so its copy gets repaired.

Overlap. #9070 rewrites this same migration so it removes the seed instead, and the two will conflict. This migration is not in a tagged release yet, so changing it in place reaches every machine that has not run it.

Waiting on the maintainer: whether this lands as the interim fix ahead of #9070.