Hello,
just a short question ... which Pihole functions are affected when "sudo" is uninstalled?
BR, Martin
sudo is a Pi-hole dependency. It won't even install if that is missing or non-functional.
You might want to look through the installer script and see where sudo is used as a dependency, etc.
You could run everything as the root user but that's a very, very bad idea.
Hello Dan
Thank you for your replay. : +1: (... and also to all other helpers)
Ok, only for the installer or also at runtime? If it also need at runtime, which functions will not work, if sudo is uninstalled?
That's not right, it was installed by the installer... possibly as a dependency on something else... see for yourself:
# cat /var/log/apt/history.log | egrep "18:19" -A 1
Start-Date: 2019-09-14 18:19:03
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 --yes --no-install-recommends install dialog dhcpcd5 git
Start-Date: 2019-09-14 18:19:55
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 --yes --no-install-recommends install curl dnsutils netcat psmisc sudo idn2 sqlite3 dns-root-data resolvconf lighttpd php-common php-cgi php-sqlite3
Before running the installer, neither sudo nor dhcpcd5 were installed. Ok, pihole is working as intended, with restricted permissions by the user pihole, all is ok:
# ps -aux | grep pihole
pihole 464 0.0 0.4 21016 8488 /lib/systemd/systemd --user
pihole 465 0.0 0.1 22984 2196 (sd-pam)
pihole 480 0.1 1.1 417640 23284 /usr/bin/pihole-FTL
But the 2 Packages sudo and dhcpcd5 are unwanted. dhcpcd5 is bloatware and not needed in a static IPv4-Net, and its also not needed in an IPv6-Net, because IPv6-Addresses are generated stateless by Kernel. I uninstalled it immediately. And sudo is ...in all short... a exploit.
This is an exploit and absolutely a Nogo:
# cat /etc/sudoers.d/pihole
www-data ALL=NOPASSWD: /usr/local/bin/pihole
The key question remains: If pihole is ready installed, which function are not working, if sudo is uninstalled.
BR, Martin
Honestly I don't know the answer to your question. I've never run any operating system without sudo. If you consider sudo to be an exploit or the pihole command to be nogo then you probably don't want to run Pi-hole.
1 Like
I think the best path is to uninstall sudo and see.
Hello Dan
I'm not saying that Pihole is a Nogo, why do you think so? Pihole is working fine. That's not what it's all about. The problem is a matter of principle and conceptual.
A program that can procure itself root privileges at runtime, so that change (or be able to change) the installation basis of the computer outside the control of an admins, is an absolute NoGo. That would be a repeat of all the design flaws that have long time been known in Windows and that cause there such big problems with malware. It also contradicts the principles of Linux, that a program must be executed, without acquiring unauthorized root privileges at runtime.How should an administrator guarantee the integrity of a system, if he don't have control about running processes ? So it's not about Pihole and that Pihole has bad intentions, but about that Pihole privileges can be abused.
I never run a Client-User-System with sudo, because every sudo-Statement leaves the system unclosed about 10 or 15 minutes.
Yes, I will try it. Is there any advice where I have to take a closer look? Special logs? Or specific behavior? Do I have to update lists manually? Or is it enough to watch that obvious in the Web-Gui?
Pi-hole needs to bind to port 53 at the very minimum. How you can do that without root priv's would be an interesting experiment.
Pi-Hole maintains it's logs in /var/log.
List updates and other admin functions are done via cron scripts installed by Pi-Hole. Here is an example of the scripts that are installed:
-rw-r--r-- 1 root root 1703 Sep 15 18:12 /etc/cron.d/pihole
9 3 * * 7 root PATH="$PATH:/usr/local/bin/" pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log
00 00 * * * root PATH="$PATH:/usr/local/bin/" pihole flush once quiet
@reboot root /usr/sbin/logrotate /etc/pihole/logrotate
*/10 * * * * root PATH="$PATH:/usr/local/bin/" pihole updatechecker local
20 14 * * * root PATH="$PATH:/usr/local/bin/" pihole updatechecker remote
@reboot root PATH="$PATH:/usr/local/bin/" pihole updatechecker remote reboot
Hi Dan
# ss -tulpn | grep 53
udp UNCONN 0 0 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=473,fd=4)) uid:998 ino:13177 sk:1 <->
udp UNCONN 0 0 [::]:53 [::]:* users:(("pihole-FTL",pid=473,fd=6)) uid:998 ino:13179 sk:2 v6only:1 <->
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=473,fd=5)) uid:998 ino:13178 sk:6 <->
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=473,fd=7)) uid:998 ino:13180 sk:a v6only:1 <->
Pihole was installed in a libvirt-KVM only as a DNS-Filter and it was installed by root. If you can see above (some posts before), the user-context is switched to user "pihole". It seems all to be ok. Pihole is working really successful.
So it is not without root-Permissions. The difference is, I do all what I have to do, with root-Permissions as user root. And I do that only in a root-shell, and never as a normal user, who allways is unprivileged. And I never start a GUI-App with sudo, because the whole X-System with all running programms can acquiring unauthorized root-Permissions.
OK, sudo is now successfully uninstalled:
The counter for requests and blocking increases as before. The missing sudo (and dhcpd) does not seem to cause any problems. Neither the journal nor the pihole logs contain clues about problems. Not even after a reboot of the system. It seems to be all ok. hmmmm
Maybe someone else has an idea what to look for?
Thank you, thats important. I think, that means I just have to see if the lists in / etc / pihole are updated ... which should actually fail because the lists belong to root: root. Probably that would be a case for "sudo". But I can solve it in an alternate way.
And these:
pi@noads:~ $ apt rdepends sudo
sudo
Reverse Depends:
Depends: fpart (>= 1.8.12)
Depends: picap
sudo-ldap
Depends: ucspi-tcp-src
sudo-ldap
Depends: qmail-src
sudo-ldap
|Recommends: winetricks
sudo-ldap
Depends: publicfile-installer
sudo-ldap
Depends: matlab-support
sudo-ldap
Suggests: zabbix-server-pgsql
sudo-ldap
Suggests: zabbix-server-mysql
sudo-ldap
Depends: xnetcardconfig
sudo-ldap
Suggests: xfce4-session
sudo-ldap
Depends: xdeb
sudo-ldap
Recommends: xara-gtk
sudo-ldap
Recommends: wicd-curses
sudo-ldap
Recommends: wicd-cli
sudo-ldap
Suggests: whalebuilder
sudo-ldap
Suggests: wajig
sudo-ldap
Depends: waagent
sudo-ldap
Depends: vagrant-lxc
sudo-ldap
Depends: v4l2loopback-utils
sudo-ldap
Depends: ubuntu-dev-tools
sudo-ldap
Replaces: sudo-ldap
sudo-ldap
Conflicts: sudo-ldap
Recommends: sshuttle
sudo-ldap
Recommends: smb4k
sudo-ldap
Depends: sidedoor-sudo
sudo-ldap
Depends: secvpn
sudo-ldap
Depends: sbackup
sudo-ldap
Recommends: ranger
sudo-ldap
Suggests: qemu-user-static
sudo-ldap
Suggests: qemu-user
sudo-ldap
Recommends: q4wine
sudo-ldap
Depends: python3-oslo.rootwrap
sudo-ldap
Depends: python-oslo.rootwrap
sudo-ldap
Depends: python-nova
sudo-ldap
Depends: plinth
sudo-ldap
Depends: piuparts-slave
sudo-ldap
Suggests: pconsole
sudo-ldap
Recommends: pbuilder
sudo-ldap
Recommends: opennebula-common
sudo-ldap
Recommends: open-infrastructure-system-config
sudo-ldap
Recommends: open-infrastructure-container-tools
sudo-ldap
Suggests: nsntrace
sudo-ldap
Depends: neutron-plugin-nec-agent
sudo-ldap
Depends: neutron-openvswitch-agent
sudo-ldap
Depends: neutron-linuxbridge-agent
sudo-ldap
Depends: neutron-l3-agent
sudo-ldap
Depends: neutron-dhcp-agent
sudo-ldap
Suggests: mountpy
sudo-ldap
Depends: mini-buildd
sudo-ldap
Recommends: mercurial-buildpackage
sudo-ldap
Recommends: live-config
sudo-ldap
Enhances: liquidprompt
sudo-ldap
Depends: linaro-image-tools
sudo-ldap
Recommends: libgksu2-0
sudo-ldap
Depends: ldap-account-manager-lamdaemon
sudo-ldap
Depends: lava-dispatcher
sudo-ldap
Depends: kdesudo
sudo-ldap
|Depends: jenkins-debian-glue
sudo-ldap
Depends: ironic-common
sudo-ldap
Recommends: inxi
sudo-ldap
Recommends: hobbit-plugins (>= 1.7.2p1-1)
Suggests: harden-environment
sudo-ldap
Suggests: harden
sudo-ldap
Depends: gnumed-server
sudo-ldap
Depends: gksu
sudo-ldap
Suggests: git-buildpackage
sudo-ldap
Recommends: geximon
sudo-ldap
Suggests: fvwm-crystal
sudo-ldap
Depends: freedombox-setup
sudo-ldap
Suggests: etckeeper (>= 1.7.4p4)
Depends: docbookwiki (>= 1.7.2p1-1)
Depends: emdebian-crush
sudo-ldap
Depends: elida
sudo-ldap
Recommends: education-standalone
sudo-ldap
Depends: dtc-xen
sudo-ldap
Recommends: drobo-utils
sudo-ldap
Depends: dpsyco-sudo
sudo-ldap
Recommends: apt-dater-host
sudo-ldap
Recommends: dkms
sudo-ldap
Depends: diaspora-common
sudo-ldap
Depends: debian-installer-launcher
sudo-ldap
Depends: debci
sudo-ldap
Depends: ctdb
sudo-ldap
Suggests: configure-debian
sudo-ldap
Recommends: check-mk-multisite
sudo-ldap
Recommends: bundler
sudo-ldap
Depends: bashburn
sudo-ldap
Recommends: auto-apt
sudo-ldap
Depends: arriero
sudo-ldap
Recommends: ara
sudo-ldap
Recommends: apt-src
sudo-ldap
That was'nt unfortunately the question 
"winetricks" is definitely no pihole dependence. A better fitting attempt would be
apt rdepends sudo | grep -i pihole
And you will notice that "sudo" also works without pihole.
To see, if pihole depend from sudo show this statement:
apt rdepends pihole
And you will notice that nothing is found.
Pihole was not installed from a Distribution-Repository, therefore there are no apt-dependencies. This is not a real problem, but my question can only be explained by the developers. Pihole can really be a valuable and great program, it just should not break elemental security rules. As long as I can set the permissions myself and prevent unauthorized root privileges, that's all ok.
I know.
I was just showing a way how to figure out if you have packages installed that depend on sudo.
If you have software installed thats on the list, it will most likely break or get pulled down when removing sudo 