wrong permissions on sudo* files

[asbi12]

This is a: Bug

The sudo configuration in the Pi-hole Docker container appears to be broken in certain setups (mine), preventing the container from functioning as expected. A manual fix via s6-init is required to repair permissions and enable full (web admin ui) functionality.
Related Issues

[X] I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar.

How to reproduce the issue

1. Environment data
   Operating System: Debian 12
   Hardware: x86-based server
   Kernel Architecture: x86_64 (6.1.0-28-amd64)
   Docker Install Info and Version: Docker CE 27.3.1, Official Docker CE repository
   Hardware Architecture: x86_64

2. docker-compose.yml contents

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "192.168.178.5:8080:80/tcp" # Only listen on specific host's IP; port 80 is in use by another container
    environment:
      TZ: 'Europe/Berlin'
    restart: unless-stopped

3. Steps to reproduce
   Start the container using the provided docker-compose.yml file.
   Attempt to interact with Pi-hole via the web interface (/admin).
   Observe the following errors:
   Settings do not apply.
   Docker logs (docker logs pihole) show the following:

    sudo: /etc/sudo.conf is world writable  
    sudo: /etc/sudoers is world writable  
    sudo: no valid sudoers sources found, quitting  
    sudo: error initializing audit plugin sudoers_audit  
   

Alternatively, try the following steps:
Run docker compose up --remove-orphans -d.
Enter the container with docker exec -it --user root pihole bash.
Execute sudo pihole.

Observe the same output:
sudo: /etc/sudo.conf is world writable  
sudo: /etc/sudoers is world writable  
sudo: no valid sudoers sources found, quitting  
sudo: error initializing audit plugin sudoers_audit  

WORKAROUND

I added a script to s6-init via a Docker volume:
'./s6-fixes:/etc/s6-overlay/s6-rc.d/zz-FIXES'.

The script runs as a oneshot with dependencies on pihole-FTL, lighttpd, and _startup.

The script fixes the broken sudo configuration by adjusting ownership and permissions for /etc/sudo* files, followed by restarting Pi-hole functionality.

To enable the script, run:
docker exec pihole touch /etc/s6-overlay/s6-rc.d/user/contents.d/zz-FIXES.
These common fixes didn't work for my issue

[X] I have tried removing/destroying my container and re-creating a new container.
[X] I have tried fresh volume data by backing up and moving/removing the old volume data.
[X] I have tried running the stock docker run example(s) in the README (removing any customizations I added).
(Excluding port changes, as port 80 is already in use on my machine.)
[ ] I have tried a newer or older version of Docker Pi-hole.
(I have not yet tried this, as my workaround enables the use of the current version.)
[X] I have tried running without my volume data mounts to eliminate volumes as the cause.
(Yes, see my Docker Compose file; I am not currently using volumes. I started clean and plan to restore via Teleporter.)

This bug may relate to incorrect permissions or configuration for /etc/sudo* files in the base Docker image. A fix in the image would eliminate the need for manual intervention.

Alternatively, it might be specific to my setup, although this is a clean Debian VM with minimal configuration (just Docker and some containers).

If it is just my setup, please advise how I can analyze why this happens.

after fresh compose, when changing anything via /admin:

after permissions fix (chown -R root:root / chmod -R 440 sudo*):

[dschaper]

What are your volume mounts? Can you post your full docker-compose.yml file please?

docker exec -it --user root pihole bash

Why are you entering as root and then trying to use a sudo command? Root doesn't need sudo, it already is a super-user account.

Execute sudo pihole

That's not a valid command, you at least need to use the pihole user to call any pihole commands and you need to then supply the pihole command with a flag to indicate what you would like to do. That's why you are seeing the 'Usage' instructions.

[asbi12]

What are your volume mounts? Can you post your full docker-compose.yml file please?

Hi, thanks for commenting, I am sorry for not being clear.
I did add the full docker file contents in the original post, under 2. (except original formatting, I did not know how to paste it here in yaml style).

There are NO volumes in the compose file, if that was the question.
That is always my first test of any container, without external mounts, if and when it works in a clean state, I try to compose down and up again with mounts to persist settings.in the future.
As the permissions are wrong on /etc/sudo*, I do not think it had anything to do with mounts.

Why are you entering as root and then trying to use a sudo command? Root doesn't need sudo, it already is a super-user account.

Yes, sure, but I was testing why the container is not working correctly, and as the log always shows those errors regarding sudo-files, I tried to do what www-data does when one edits anything though the admin page: sudo pihole [whatever command]

The "sudo pihole" was just an example, as that should at least write the possible commands to the console when calling just "sudo pihole", which it does not, it gives the errors I wrote because of wrong permissions.
The exact same errors appear anytime I change anything in the web gui /admin, because lighttpd (www-data) needs to call sudo pihole (which it should be able to, reading the corresponding sudo file (which grants www-data running sudo pihole without password).

It just fails because of the permissions, which I am trying to understand.

Execute sudo pihole

That's not a valid command, you at least need to use the pihole user to call any pihole commands and you need to then supply the pihole command...

Yes, I am aware. However to make my actual issue clear:
Executing "sudo pihole" or any other command with sudo (right or wrong) does fail until I use my current workaround to fix the permissions.
Only after that I get the supported command output at all from "sudo pihole".
And only after that the web admin can be used to change anything.

I hope that is clearer now.
I can (and did) work around the issue, but I'd really like to understand how this error can appear in the first place,