pihole.log permissions on tmpfs /var/log

[bebo-dot-dev]

In raising this issue, I confirm the following:

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated.
• The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:

1

---

Expected behaviour:

After initial install or upgrade and reboot of the device running pihole, pihole / pihole-FTL is able to fully start with no errors reported in pihole-FTL.log about permissions

Actual behaviour:

After initial install or upgrade and reboot of the device running pihole, pihole-FTL is unable to start and I see an error reported in /var/log/pihole-FTL.log related to lack of permissions to pihole.log:

[2017-12-08 08:32:48.261] WARN:  Opening of /var/log/pihole.log failed!
[2017-12-08 08:32:48.261]        Make sure it exists and is readable by user pihole
       Will try again in 15 seconds.
[2017-12-08 08:33:20.199] FATAL: Opening of /var/log/pihole.log failed permanently!

Although pihole-FTL was unable to start, ad blocking continues to work as expected.

Steps to reproduce:

1. mount /var/log on tmpfs in fstab: tmpfs /var/log tmpfs defaults,noatime,nosuid,mode=0755,size=100m 0 0
2. install pihole
3. reboot the device
4. verify that pihole-FTL has failed to start: pihole-FTL running
5. verify the startup failure related to permissions to /var/log/pihole.log in /var/log/pihole-FTL.log (shown above in the "Actual behaviour" section)

Troubleshooting undertaken, and/or other relevant information:

I've been able to fix this by manually modifying /etc/init.d/pihole-FTL so that /var/log/pihole.log exists and permissions are modified so that the pihole user initially owns /var/log/pihole.log on startup:

# Start the service
start() {
  if is_running; then
    echo "pihole-FTL is already running"
  else
    touch /var/log/pihole-FTL.log /run/pihole-FTL.pid /run/pihole-FTL.port /var/log/pihole.log
    chown pihole:pihole /var/log/pihole-FTL.log /run/pihole-FTL.pid /run/pihole-FTL.port /etc/pihole /var/log/pihole.log
    chmod 0644 /var/log/pihole-FTL.log /run/pihole-FTL.pid /run/pihole-FTL.port
    su -s /bin/sh -c "/usr/bin/pihole-FTL" "$FTLUSER"
    echo
  fi
}

Please note the parts that I've added to touch and chown /var/log/pihole.log here.

This change appears to enable the pihole-FTL process to start with no issues however I note that after startup, the /var/log/pihole.log is owned by dnsmasq. This change is a permanent fix until pihole is upgraded because the /etc/init.d/pihole-FTL init.d script is overwritten when pihole is upgraded.

I "think" this issue could be related to me mounting /var/log on tmpfs which I do to prolong SD card life.

I'm running pihole on a NanoPi Neo2 device which is running:
ARMBIAN 5.27 stable Ubuntu 16.04.2 LTS 4.11.1-sun50iw2

My current version:
Pi-hole Version v3.2 Web Interface Version v3.2 FTL Version vDev-437af07

I experienced this issue for the second time since initial install today when I upgraded to v3.2 and the upgrade rewrote/overwrote my manually adjusted /etc/init.d/pihole-FTL init.d script

Thanks!

[AzureMarker]

Is this a Pi-hole issue, or just an issue with using tmpfs?

[bebo-dot-dev]

Thanks, I'm sorry I don't know to be honest.

The error reported in /var/log/pihole-FTL.log is a permissions problem and I can confirm that the change I've made to the /etc/init.d/pihole-FTL init.d script does fix the problem but I don't know why this condition occurs or why the pihole user would have access to /var/log/pihole.log on other systems with no permission change similar to the one I'm having to make.

The only thing I can think of that is slightly different / non-standard about my setup is my use of log2ram (included in armbian) which mounts /var/log as a tmpfs volume.

I'll run some further tests this weekend disabling the fstab tmpfs mount and I'll report back with what I find. It might be worth me asking now if pihole is supported on with /var/log mounted as a tmpfs? I have searched but I couldn't find anything conclusive one way or the other.

[AzureMarker]

In the installer we set the permissions so pihole can read it:

chmod 644 /var/log/pihole.log

[bebo-dot-dev]

That's good to know, but what would happen on a "normal" system (not mine :)) if /var/log/pihole.log was to somehow get deleted, basically simulating what happens on my system at boot time where /var/log is effectively empty?

In this scenario what process creates the brand new /var/log/pihole.log at runtime and sets 0644 on this new file? The evidence appears to suggest that it's dnsmasq creating the file and nothing is setting 0644 on the new file.

[AzureMarker]

It might set it to 640 dnsmasq:root automatically. However, in normal operation the log file is managed through logrotate, which keeps the permissions of the original log.

[bebo-dot-dev]

Yes that aligns with what I see when I remove my init.d change and reboot. pihole.log is recreate, by dnsmasq I assume and is owned by dnsmasq, group root and no others can read:

root@nanopineo2:~# stat /var/log/pihole.log
  File: '/var/log/pihole.log'
  Size: 50923     	Blocks: 104        IO Block: 4096   regular file
Device: 29h/41d	Inode: 8297        Links: 1
Access: (0640/-rw-r-----)  Uid: (  109/ dnsmasq)   Gid: (    0/    root)
Access: 2017-12-08 21:59:28.404000001 +0000
Modify: 2017-12-08 22:01:32.225913675 +0000
Change: 2017-12-08 22:01:32.225913675 +0000
 Birth: -

Do you think a pull request for a change to the pihole-FTL init.d script would be accepted to make it more friendly to non-existence of the pihole.log file?

[AzureMarker]

Maybe, depends on how portable it is. Give it a go, and we'll review it.

[bebo-dot-dev]

Cheers, #1817 is opened

[bebo-dot-dev]

I see that #1817 has been merged to the development branch, thanks guys great work.

Closing this down now.