OmarchybotandClaude Opus 5
c0b593b349
Backport of the docker group removal (PR #8056, merged to quattro as b5ded31e)
onto the v4-0-1 release branch.
The docker group is root-equivalent: anything in it can docker run -v /:/host
and rewrite the host as root with no password. On a single-user box that is not
an escalation -- the owner is already a wheel user -- but it hands any code
running as the user, a rogue plugin or a poisoned dependency, a silent,
headless, passwordless path to root that sudo's password prompt would otherwise
gate.
Stop granting the group by default. The daemon still runs, the Docker TUI and
the Windows VM reach it through a polkit prompt, and the plain docker CLI runs
under sudo. Sudoless Docker becomes a warned opt-in under Setup > Security, and
no automatic path re-grants it: install and first-boot provisioning never record
or apply the group, and the Quattro upgrade no longer adds it. A migration takes
existing installs out of the group, reusing omarchy-remove-security-sudoless-
docker so the change and its notice have one source of truth.
The Windows VM keeps needing the root daemon for a privileged container, so it
runs without the group without becoming a new way in: the compose moves to a
root-owned directory written only by an elevated, input-validated writer, volume
paths are rebuilt from $HOME on migration rather than trusted from the
user-writable legacy file, the privileged sub-action is checked against an
allowlist before dispatch, pkexec elevates a verified root-owned command path,
mount sources are refused when they are or resolve through a symlink, and the
guest password moves to a private 0600 per-user file instead of a
world-readable compose. Existing installs auto-migrate the VM without a
redownload.
Two files had diverged from quattro and were resolved by hand:
bin/omarchy-windows-vm -- v4-0-1 still carries the "Starting Windows VM" toast
that #7585 dropped on quattro, and the new start path has no user-side status
check to hang it on: after this change the user cannot inspect the container
without privilege, which is the whole point. Took quattro's version. #7585's
reason holds here too -- the shell shows its own "Launching Windows…" OSD until
the RDP window appears (shell/services/AppLibrary.qml) -- and the failure
notification stays. The file is now byte-identical to quattro.
manual/28-windows-vm.md -- took the new paragraph on the root-owned compose,
without the neighbouring OEM-key paragraph, which documents omarchy windows key,
a command quattro has and this branch does not.
test/shell passes here: 186 files, including the three this adds.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018DEMYa9UWtroz93DhMTtcV
66 lines
2.9 KiB
Bash
66 lines
2.9 KiB
Bash
#!/bin/bash
|
|
#
|
|
# The docker-group opt-in migration must remove an existing install's user from
|
|
# the root-equivalent docker group (only when they are in it), refresh the stale
|
|
# Docker launcher entry, and stay idempotent on reruns.
|
|
|
|
set -euo pipefail
|
|
|
|
source "$(dirname "${BASH_SOURCE[0]}")/base-test.sh"
|
|
|
|
migration="$ROOT/migrations/1787580187.sh"
|
|
test_dir=$(mktemp -d)
|
|
trap 'rm -rf "$test_dir"' EXIT
|
|
|
|
home="$test_dir/home"
|
|
omarchy_path="$test_dir/omarchy"
|
|
stub_bin="$test_dir/bin"
|
|
mkdir -p "$home/.local/share/applications" "$omarchy_path/applications" "$stub_bin"
|
|
|
|
# The packaged (new) launcher entry the migration should copy over the stale one.
|
|
printf 'NEW-LAUNCHER\n' >"$omarchy_path/applications/Docker.desktop"
|
|
printf 'OLD-LAUNCHER\n' >"$home/.local/share/applications/Docker.desktop"
|
|
|
|
# Stub id to report a controllable group set, and the removal command to record
|
|
# that it was called instead of touching the real system.
|
|
cat >"$stub_bin/id" <<'STUB'
|
|
#!/bin/bash
|
|
# Only the migration's `id -nG "$USER"` needs answering here.
|
|
printf '%s\n' "${STUB_GROUPS:-wheel input}"
|
|
STUB
|
|
cat >"$stub_bin/omarchy-remove-security-sudoless-docker" <<'STUB'
|
|
#!/bin/bash
|
|
touch "${REMOVE_CALLED:?}"
|
|
STUB
|
|
chmod +x "$stub_bin/id" "$stub_bin/omarchy-remove-security-sudoless-docker"
|
|
|
|
remove_called="$test_dir/remove-called"
|
|
run_migration() {
|
|
rm -f "$remove_called"
|
|
HOME="$home" OMARCHY_PATH="$omarchy_path" USER="tester" \
|
|
STUB_GROUPS="$1" REMOVE_CALLED="$remove_called" \
|
|
PATH="$stub_bin:$PATH" bash -euo pipefail "$migration" >/dev/null 2>&1
|
|
}
|
|
|
|
# In the docker group: the user is removed and the launcher is refreshed.
|
|
run_migration "wheel input docker" || fail "migration runs when the user is in the docker group"
|
|
[[ -e $remove_called ]] || fail "migration removes a user who is in the docker group"
|
|
[[ $(cat "$home/.local/share/applications/Docker.desktop") == "NEW-LAUNCHER" ]] ||
|
|
fail "migration refreshes the stale Docker launcher entry"
|
|
pass "migration removes the docker group and refreshes the launcher"
|
|
|
|
# Not in the docker group (fresh install, or already migrated): no removal.
|
|
printf 'OLD-LAUNCHER\n' >"$home/.local/share/applications/Docker.desktop"
|
|
run_migration "wheel input" || fail "migration runs when the user is not in the docker group"
|
|
[[ ! -e $remove_called ]] || fail "migration must not call the removal when the user is not in the docker group"
|
|
[[ $(cat "$home/.local/share/applications/Docker.desktop") == "NEW-LAUNCHER" ]] ||
|
|
fail "migration still refreshes the launcher when the group is already absent"
|
|
pass "migration is a no-op on the group when it is already absent"
|
|
|
|
# No launcher entry present: the refresh is skipped without error.
|
|
rm -f "$home/.local/share/applications/Docker.desktop"
|
|
run_migration "wheel input" || fail "migration tolerates a missing launcher entry"
|
|
[[ ! -e $home/.local/share/applications/Docker.desktop ]] ||
|
|
fail "migration does not create a launcher entry that was not there"
|
|
pass "migration skips the launcher refresh when no entry exists"
|