Package Details: pi-hole-ftl 5.25.2-2

Git Clone URL: https://aur.archlinux.org/pi-hole-ftl.git (read-only, click to copy)
Package Base: pi-hole-ftl
Description: The Pi-hole FTL engine
Upstream URL: https://github.com/pi-hole/FTL
Licenses: EUPL-1.2
Conflicts: dnsmasq
Provides: dnsmasq
Submitter: max.bra
Maintainer: max.bra (graysky)
Last Packager: max.bra
Votes: 56
Popularity: 1.38
First Submitted: 2017-05-07 15:23 (UTC)
Last Updated: 2024-08-10 09:53 (UTC)

Required by (65)

Sources (6)

Pinned Comments

max.bra commented on 2018-02-09 16:46 (UTC) (edited on 2019-10-18 23:13 (UTC) by max.bra)

ArchLinux Pi-hole is not officially supported by Pi-hole project. In case of bugs and malfunctions please DO NOT file a report upstream.

First of all check if the wiki (https://wiki.archlinux.org/index.php/Pi-hole) can help then ask here for assistance and tips.
When it will be excluded that the problem does not depend on ArchLinux we will file a bug upstream.

Latest Comments

« First ‹ Previous 1 .. 19 20 21 22 23 24 25 26 27 28 29 .. 44 Next › Last »

max.bra commented on 2020-02-26 10:55 (UTC)

aah ok i see. updated w/o version bump.

MarcinWieczorek commented on 2020-02-26 10:34 (UTC)

https://wiki.archlinux.org/index.php/Makepkg

Packages can be built into one directories and the sources can be stored in one directory too. Names like vX.X.X cause conflicts and lead to false negatives on checksum checking.

max.bra commented on 2020-02-26 10:23 (UTC)

@MarcinWieczorek can you be more specific please? what is a shared source directory and why do that?

MarcinWieczorek commented on 2020-02-26 10:16 (UTC)

Please rename the tarball to include $pkgname for use in shared source directories. Thanks.

max.bra commented on 2020-02-24 21:50 (UTC)

@Mettacrawer nice!! Thanks.

Mettacrawer commented on 2020-02-24 12:16 (UTC) (edited on 2020-02-24 12:23 (UTC) by Mettacrawer)

In /srv/http/pihole/admin/scripts/pi-hole/php/sub.php around line 44 you will see that updates to the blacklist and the whitelist are made by running the /usr/bin/pihole command via sudo. For some strange reason updates to /etc/pihole/regex.list are made by just writing to that file. You can see if(file_put_contents($regexfile, $list."\n") === FALSE) in /srv/http/pihole/admin/scripts/pi-hole/php/sub.php

This is important because the /usr/lib/systemd/system/pihole-FTL.service unit file runs ExecStartPre=/bin/chown -R pihole:pihole /etc/pihole which locks up /etc/pihole/regex.list causing the webui to fail when trying to add regex whitelist and blacklist entries.

My work around is to use

    ExecStartPre=/bin/chown -R pihole:pihole /etc/pihole
    ExecStartPre=/bin/chown pihole:http /etc/pihole/regex.list
    ExecStartPre=/bin/chmod g+w /etc/pihole/regex.list

But there's probably other ways to work around.

graysky commented on 2019-12-24 20:52 (UTC)

@peacey - You probably want to add that to the wiki... I switched over the lighttpd to circumvent.

graysky commented on 2019-12-13 18:52 (UTC)

@peacey - Thank you... I opened an issue upstream referencing your post: https://github.com/pi-hole/pi-hole/issues/3039

peacey commented on 2019-12-13 18:43 (UTC) (edited on 2019-12-13 19:24 (UTC) by peacey)

@graysky, the problem is the latest version of php-fpm has a systemd service file that adds restrictions in order to sandbox processes better (no elevated permissions with sudo, read-only file system, etc). These restrictions interfere with PiHole because the PiHole web files need access to sudo and a writable /etc to run the pihole executable to get status and enable/disable from the web (which is also broken now).

Solution is to add an override to php-fpm.service and allow certain capabilities that PiHole needs. Run "sudo systemctl edit php-fpm.service" and copy the following,

[Service]
# Only set /usr and /boot to read-only, set /etc to read-write
ProtectSystem=true
# Allow for privilege escalation of child processes, needed to use sudo in php scripts
NoNewPrivileges=false
# Add needed capabilities
CapabilityBoundingSet=CAP_SETGID CAP_SETUID CAP_SYS_RESOURCE CAP_DAC_OVERRIDE CAP_KILL

Then restart php-fpm service. CAP_SYS_RESOURCE is for using sudo properly (need access to setrlimit), CAP_DAC_OVERRIDE is for allowing change to files that aren't owned by calling process with sudo, and CAP_KILL is so the pihole web app can disable itself by killing the pihole-ftl process.

It seems to me there are glaring security implications by doing these changes, so do this at your own risk. But the way pihole is written where the PHP script needs access to run sudo, I don't see how else it would be possible. PiHole needs to update their PHP script to use an external daemon that doesn't require sudo to call it but uses some type of internal authentication instead.

Edit: Also, next version of php-fpm, 7.4.1, is removing the CapabilityBoundingSet restrictions and NoNewPrivileges, but it still has ProtectSystem set to full (read-only /etc). So you'll probably still need the first override with the next update. See https://bugs.archlinux.org/task/64781?project=1&string=php-fpm and https://github.com/php/php-src/blob/PHP-7.4.1/sapi/fpm/php-fpm.service.in.

« First ‹ Previous 1 .. 19 20 21 22 23 24 25 26 27 28 29 .. 44 Next › Last »