Ensure pihole-FTL can write to all files in /etc/pihole, /run/pihole and /var/log/pihole

[yubiuser]

What does this PR aim to accomplish?:

In v5 we create custom.list with owner root.

pi-hole/automated install/basic-install.sh

Lines 1374 to 1380 in 8495565

	# Install empty custom.list file if it does not exist
	if [[ ! -r "${PI_HOLE_CONFIG_DIR}/custom.list" ]]; then
	if ! install -o root -m 644 /dev/null "${PI_HOLE_CONFIG_DIR}/custom.list" &>/dev/null; then
	printf " %b Error: Unable to initialize configuration file %s/custom.list\\n" "${COL_LIGHT_RED}" "${PI_HOLE_CONFIG_DIR}"
	return 1
	fi
	fi

However, in v6 FTL needs to write to the file after dropping priviledges/as user pihole.

2023-08-03 20:20:48.970 [9285M] INFO: FTL version: vDev-a9d4771
2023-08-03 20:20:48.970 [9285M] INFO: FTL commit: a9d47713
2023-08-03 20:20:48.970 [9285M] INFO: FTL date: 2023-07-28 23:46:26 +0200
2023-08-03 20:20:48.971 [9285M] INFO: FTL user: pihole
2023-08-03 20:20:48.971 [9285M] INFO: Compiled for linux/arm64/v8 (compiled on CI) using cc (Alpine 12.2.1_git20220924-r10) 12.2.1 20220924
2023-08-03 20:20:49.012 [9285M] INFO: Writing config file
2023-08-03 20:20:49.044 [9285M] ERR: Cannot open /etc/pihole/custom.list for writing, unable to update custom.list: Permission denied

This PR sets the owner on installation to pihole and ensures that before FTL is started the owner is set to pihole for existing files.

P.S. We could also set a transition path v5 -> v6 to change owner of all files in /etc/pihole/ to pihole instead of root.

---

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

[DL6ER]

We should add a -R. Any file in /etc/pihole should be writable by pihole:pihole and doing so before each FTL start ensures permission issues possibly created by users manually tinkering around as root can easily be fixed by restarting FTL

[yubiuser]

I added a second commit that will set pihole:pihole for all files/folders in /etc/pihole, /var/log/pihole and /run/pihole

[DL6ER]

Thanks for your change. I wonder though (this is entirely up for discussion!) if we should drop those chmods as well (read as: they are dropped here, but I think they shouldn't).

My initial idea would be that we should set 640 (u+rw,g+r) on the log files but something more generous on the config files (like 660 -> u+rw,g+rw) so that other users manually added the the group pihole can edit such files.

What we currently do (granting read permissions for all) on the

• macvendor.db,
• dhcp.leases, and
• FTL.log

shouldn't be needed.

If FTL.log would contain query information (only if debug.queries = true), one might very well even consider this a privacy issue - we should definitely have the last digit 0 for such files.

Summary: I don't think there is anything (also not custom.list) that would need read permissions for all. 660 seems the way to go.

[yubiuser]

I agree with the requested changes in re-adding file permission. Having 640for the log files and 660 for the config files seems to be a good balance. See also #4760

[DL6ER]

What is the reason for allowing other users from being able to access the directories when if they aren't allowed to read any files in there?

[yubiuser]

My idea was: others can access the dir and get the names of the files within but not the actual content of the files.

[PromoFaux]

Looks good to me, but as @DL6ER last requested changes, will await his approval/not to merge