06a3dbca42
* Offer to reboot when toggling sudoless Docker; show only the relevant menu entry Group membership only takes effect on a fresh session, and in practice a logout or newgrp isn't enough — only a reboot reliably applies it. So the setup/remove commands now flag the reboot and offer to do it now with a gum confirm (like the GPU toggle), and the notices say "after a reboot" instead of pointing at logout or newgrp. The existing-user migration passes OMARCHY_DEFER_REBOOT so it does not prompt mid-update — omarchy-update-restart still handles the reboot once the whole update finishes. The Setup > Security menu also showed Sudoless Docker under both Setup and Remove. Condition the Setup entry on the group being absent (Remove already conditions on it being present), so only the applicable one appears. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T * Ask omarchy-sudo-docker whether Docker needs sudo Every place that chooses between talking to Docker directly and elevating was testing group membership by hand, and the menu guards tested the wrong thing: they read the running session's groups, which do not change until the reboot, so after enabling sudoless Docker the menu still offered Setup — the one action that could no longer do anything — while Remove stayed hidden. Add omarchy-sudo-docker as the single answer, with the two questions that actually differ in that window. By default it asks whether this session can reach the socket, which is what decides if a command must elevate: lazydocker and the Windows VM keep prompting until the reboot lands. With --configured it asks whether the account is set up for sudoless Docker, which is what the menu and the toggles need, so the menu switches to the action that can change state as soon as the group is written. Also correct a comment: nothing surfaces reboot-required in the bar; it is omarchy-update-restart that reads it during a later update. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
35 lines
1.4 KiB
Bash
Executable File
35 lines
1.4 KiB
Bash
Executable File
#!/bin/bash
|
|
|
|
# omarchy:summary=Disable sudoless Docker by removing your user from the docker group
|
|
# omarchy:requires-sudo=true
|
|
|
|
set -e
|
|
|
|
# Ask about the configured groups, not this session's: right after enabling,
|
|
# sudoless Docker is on for the account even though the running session still
|
|
# needs a prompt, and this command is what turns it back off.
|
|
if omarchy-sudo-docker --configured; then
|
|
echo "Sudoless Docker is not enabled: $USER is not in the docker group."
|
|
exit 0
|
|
fi
|
|
|
|
echo "Removing $USER from the docker group..."
|
|
sudo gpasswd -d "$USER" docker >/dev/null
|
|
|
|
# Group membership is only re-read by a fresh session, and in practice logging
|
|
# out or newgrp isn't enough — only a reboot reliably applies it. Record it so a
|
|
# later `omarchy update` still prompts (omarchy-update-restart reads this), then
|
|
# offer to do it now.
|
|
omarchy-state set reboot-required
|
|
|
|
echo ""
|
|
echo "Sudoless Docker DISABLED. Docker access goes through a polkit/sudo prompt"
|
|
echo "again: the Docker TUI (Super + Shift + D) and the Windows VM ask when they"
|
|
echo "need it, and the plain 'docker' CLI runs under sudo. It takes effect after a reboot."
|
|
echo ""
|
|
# The migration reuses this command during 'omarchy update' and defers the
|
|
# reboot to omarchy-update-restart, so it doesn't cut the update short.
|
|
if [[ -z ${OMARCHY_DEFER_REBOOT:-} ]] && gum confirm "Reboot now to apply?"; then
|
|
omarchy-system-reboot
|
|
fi
|