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.