Skip to content

Install doas on apk-based distros + use it if sudo is unavailable #6471

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
Sparronator9999 wants to merge 1 commit into
base: development
Choose a base branch
from
Open

Install doas on apk-based distros + use it if sudo is unavailable #6471

Sparronator9999 wants to merge 1 commit into from
+30 −19

Conversation

@Sparronator9999
Copy link
Contributor

@Sparronator9999 Sparronator9999 commented Nov 11, 2025

Thank you for your contribution to the Pi-hole Community!

Please read the comments below to help us consider your Pull Request.

We are all volunteers and completing the process outlined will help us review your commits quicker.

Please make sure you

  1. Base your code and PRs against the repositories developmental branch.
  2. Sign Off all commits as we enforce the DCO for all contributions
  3. Sign all your commits as they must have verified signatures
  4. File a pull request for any change that requires changes to our documentation at our documentation repo

What does this PR aim to accomplish?:

This PR changes the privilege escalation tool used on Alpine Linux (and other apk-based distros) to doas (instead of sudo, which is deprecated since v3.15 in Alpine Linux). It also fixes #6459.

How does this PR accomplish the above?:

  • The pihole-meta package has been updated to install doas instead of sudo (including meta-package version update to v0.2).
  • All (2?) instances where sudo is called have been changed to check which privilege escalation tool is installed on the system, and use the appropriate command (sudo still takes precedence on all installations, e.g. if it was installed manually).
    • Unlike using doas-sudo-shim (as discussed in my original issue), using doas directly allows users to continue to use sudo if they wish (including for other programs that may still need it).

The only behaviour change I've noticed with doas (at least on a default install of Alpine Linux) is that it always asks for a password when running commands using it, even when running as root. This can be changed to match sudo's behaviour by adding permit nopass root to the doas.conf (not included in this PR).

Link documentation PRs if any are needed to support this PR:

N/A

By submitting this pull request, I confirm the following:

  1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
  2. I have commented my proposed changes within the code and I have tested my changes.
  3. I am willing to help maintain this change if there are issues with it later.
  4. It is compatible with the EUPL 1.2 license
  5. I have squashed any insignificant commits. (git rebase)
  6. I have checked that another pull request for this purpose does not exist.
  7. I have considered, and confirmed that this submission will be valuable to others.
  8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
  9. I give this submission freely, and claim no ownership to its content.
  • I have read the above and my PR is ready for review. Check this box to confirm

@Sparronator9999 Sparronator9999 requested a review from a team as a code owner November 11, 2025 10:31
@rrobgill
Copy link
Contributor

rrobgill commented Nov 11, 2025

The only behaviour change I've noticed with doas (at least on a default install of Alpine Linux) is that it always asks for a password when running commands using it, even when running as root.

Yes, this is not ideal. It may well be contributing to the test failures for your code.

When I install manually from your patch, even if starting the script as doas -u root basic-install.sh it stops and asks for the password again partway through the process

It also seems this would cause problems with --run-unattended.

@Sparronator9999
Copy link
Contributor Author

Sparronator9999 commented Nov 11, 2025 •
edited
Loading

If I remember correctly, doas needed some manual configuration to work on my system:

  1. Add permit persist :wheel to doas.conf to allow all administrator accounts to run doas commands (add your account to the wheel group if necessary - which it was for me IIRC).
  2. Add permit nopass root to doas.conf to allow root to run commands as other users without needing a password (matches sudo's behaviour).

Not really sure if it's a good idea to automate the former step, though.

Edit: I believe the test failure is resulting from the lack of the first config line (allowing wheel members to run doas commands).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Sparronator9999 @rrobgill