HTML Permissions

The issue I am facing:
I have yesterday (29/09/2022) successfully installed pihole on a Raspberry Pi 4B running Raspbian GNU/Linux 10 (buster). But I am now receiving an error message on the Settings page saying:

Error

There was a problem applying your settings.
Debugging information:
PHP error (2): session_start(): open(/var/lib/php/sessions/sess_bnjcn8j8ostlijp0smq8q1r4t7, O_RDWR) failed: Permission denied (13) in /var/www/html/admin/scripts/pi-hole/php/func.php:661

:

Details about my system:
I am running Apache2 as a separate service to Lighttpd which was installed with pihole. Lighttpd is using port 80. Apache2 is using a different port for a different application. The reason I have two separate http servers is because one of them runs under a different username and permissions on its subdirectory are specific to that.

What I have changed since installing Pi-hole:
I made the mistake of changing all ownership under the pihole html directory with chown -R pihole:pihole /var/www/html. This is because I assumed (wrongly) that files should not be set to root:root.

I have tried changing ownership back to root:root and also tried www-data:www-data. I have not changed any permissions (chmod).

I am pretty sure I've messed up the ownership as some files should be set as www-data, some as root and some as pihole.

I am hoping someone can please tell me what the correct permissions should be for each file and subfolder under /var/www/html, then I will try setting them back to defaults. I have tried searching the web and forums for a complete list, but without success.

/var/www/html itself is www-data www-data

Everything below that is root root

And so are the /var/www/html/admin/ as well as /var/www/html/pihole/ directories themselves.

Just a thought, as naturally, I wouldn't know about your specific web application, but I'd suggest revisiting its permission requirements.

Usually, you'd leave permissions under /var/www/html/ untouched. If a specific user would require access, you could then consider to add that user to the www-data group, e.g.
sudo usermod -a -G www-data <USER>

It may be worth investigating your other web appplication in that regard.

Should they be? On mine they are not

drwxrwxr-x 4 www-data www-data 4096 Sep 26 15:48 .
drwxr-xr-x 3 root     root     4096 Sep 11 16:54 ..
drwxr-xr-x 7 root     root     4096 Sep 23 03:06 admin
drwxr-xr-x 2 root     root     4096 Sep 19 11:40 pihole

BH... Understood, but I'm trying to keep the other web application entirely separate. It is freepbx running under user Asterisk and it has its own permissions management which I cannot modify. The whole apache webserver runs under the asterisk user and group.

Thanks for the suggestion though.

chrislf... I will give it a go. Thanks.

Thanks, you are correct - I've adjusted my post accordingly.

So, my directories and subdirectories look like chrislph, but I am still getting the error.

Any ideas what else would cause permissions to fail on /var/www/html/admin/scripts/pi-hole/php/func.php:661 ?

That particular file is root:root rw- r-- r-- (644)
I can also confirm that lighttpd is running as user www-data

Could apache have changed the permissions of /var/lib/php/sessions, maybe to apache:apache?

On mine it is

drwx-wx-wt  2 root root 4096 Sep 30 12:37 sessions

and the session inside is (with xxx... being the random string)

-rw------- 1 www-data www-data   67 Sep 30 14:08 sess_xxx...

Yes the PHP session folder and file within it is for the Apache user which is asterisk:asterisk.

With that said, the permissions were 664 and changing to 666 made no difference

You can set the correct permissions on the sessions (with an s) directory with

sudo chmod 1733 /var/lib/php/sessions
sudo chown root:root /var/lib/php/sessions

I'd be inclined to record the current permissions, halt and disable the FreePBX and Apache services, and modify the permissions as above for the purposes of testing and then reboot to see if Pi-hole is happy again. It should be creating sessions in there with the previously mentioned 600 www-data:www-data permissions.

Obviously this testing may not be practical if the PBX is in use for real needs. Sounds like you might need a separate environment or containers to keep them all happy.

Thanks Chris,

FreePBX is most certainly in use so unfortunately changing the common php folder ownership is not an option as it would break that installation.

OTOH, you gave me the idea that lighttpd can run as a different user by inserting the following values in /etc/lighttpd/external.conf. The external.conf file is outside the control of pi.hole, therefore modifications to that file will not be overwritten by pi.hole updates.

The following procedure will run lighttpd as the 'asterisk' user and group so that lighttpd can access the php sessions folder which is also being used by apache2 for the FreePBX application which is already running as that user.

Obviously, if the need arises, you could replace that with any other valid user:group.

/etc/lighttpd/external.conf

server.username  := "asterisk"
server.groupname := "asterisk"

(note the colon before the = sign means the value replaces the original "www-data" value in lighttpd.conf)

There are a number of folders which also need changing:

[edit 08/10/2022]
It has been discovered that the owner:group for the lighttpd folders will be reset to www-data by system.d on every restart which is incovenient. But we can modify system.d behaviour for lighttpd as follows.

Remember, in my case the username is 'asterisk' so you should substitute that with your own username as needed.

Navigate to /usr/lib/tmpfiles.d/lighttpd.tmpfile.conf and open with your favourite editor to change every instance of www-data to your username (in my case 'asterisk') and save.

d /run/lighttpd 0750 asterisk asterisk -
d /var/log/lighttpd 0750 asterisk asterisk -
d /var/cache/lighttpd 0750 asterisk asterisk -
d /var/cache/lighttpd/compress 0750 asterisk asterisk -
d /var/cache/lighttpd/uploads 0750 asterisk asterisk -

(note the last line is empty)

Then run the following command in the console:
chown asterisk:asterisk /var/www/html

Also, the /etc/sudoers.d/pihole file must be commented / changed to:

# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
#
# Allows the WebUI to use Pi-hole commands
#
# This file is copyright under the latest version of the EUPL.
# Please see LICENSE file for your rights under this license.
#
# www-data ALL=NOPASSWD: /usr/local/bin/pihole
asterisk ALL=NOPASSWD: /usr/local/bin/pihole

[/edit]

Remove user 'www-data' from all supplementary groups:
Depending on the use case, replace '' with a comma delimited list of
the subgroups which it needs to remain a member of.
usermod -G '' www-data

add 'pihole' as a supplementary group for asterisk
usermod -G pihole asterisk

Now, the result of $cat /etc/group | grep pihole :
pihole:x:994:asterisk

Finally, reboot the machine so that system.d will set the correct permissions for the lighttpd folders.

The pihole log now works as expected in the user interface with the correct permissions.
[Edited 02/10/2022 and 08/10/2022 to reflect the conclusions of the discussions below]

Nice idea, looks like an interesting workaround to this kind of situation, useful to know as a reference. By all means update the thread if any gotchas or tweaks come up. I guess Pi-hole's control is a layer above the PHP control and so it doesn't 'care', so to speak, only in as much as is has permissions to access it.

Edit to add – maybe this is a good candidate for moving to Docker for more general admin, as future updates could feasibly kill either app. I've not used Docker yet and need to do some reading, but from what I understand this is exactly a type of scenario it resolves cleanly.

The only minor snag I hit after changing the user and group of the lighthttp server, was it failed to read the 'Tail pihole.log' under the Tools menu. I'm not sure it was actually caused by the change in the server though as it seems to be a matter of logfile permissions.

For some reason the permissions on /var/log/pihole/pihole.log were 640 yet on /var/log/pihole/FTL.log they were 644.

chmod 644 /var/log/pihole/pihole.log

fixed it, although I cannot say if a future update might reset it.
[Edit] DO NOT DO THIS. See accepted solution above. [/Edit]

Lastly, it occurs to me that now that I have two webservers, (apache and lighttpd), both running under the same username, I could (in theory) get rid of lighttpd altogether and just specify a virtual host for pi.hole to run via apache. That's something I'll try another day.

Just replying to your edit...
I have never used Docker either so I can't comment one way or another. Sounds promising though.

I had moved FreePBX into a different webroot under /var/www/, to avoid conflicts with pihole. I think the above solution will be fairly robust to updates as the changes were added to the /etc/lighttpd/external.conf file which will never get updated. So pihole can make as many changes as it likes to the lighttpd.conf file without messing with the custom settings. It is feasible, of course, that the folder permissions might get reset. I think the developers have tried to make pihole sit alongside other deployments without modifications, but have simply "assumed" that www-data will always be the default user for the active http server. We can hope that maybe a future version will cater for that?

https://github.com/pi-hole/pi-hole/pull/4760


We already try that.

https://github.com/pi-hole/FTL/pull/659

Thanks for pointing me to this info.

I now see why the permissions have been changed to 660 for the sensible (sensitive?) pihole log and I note the discussion to replace lighttpd with a new API (which seems to have run aground?)

May I suggest that while lighttpd is still the preferred webserver, you might consider providing a new option to be included during the installation / setup procedure to choose the user:group that lighttpd will run as?

There is no reason why it must always be "www-data" and allowing custom user:group values would help mitigate the use-case where it sits alongside other web applications which share common resources like PHP sessions. If pihole is aware of the custom user:group setting, then this would allow the log file permission to work as 660 instead of 664 and play nicely with third-parties.

It's still in development, but surely this happens slowly.

That is determined by the operating system and the package defaults set by the package. We don't change any of that.

Thanks Dan,

Understood.

I assume (but stand to be corrected) that the pihole application must have the www-data:www-data user:group hard coded somewhere so that it can read and write to the pihole log file which is set to permission 640? So if the lighttpd user:group is changed, then it gets permission denied error when trying to display the file under the settings menu unless the file permission is set to 644 which is a potential security risk for some users. Maybe there are other implications elsewhere, but that is the only one I know of.

So while I perfectly understand that you install lighttpd using defaults, (and don't change it), I am suggesting that you might consider the use-case where it is changed for compatibility with other applications running on the same platform, and adapt the code to make pihole aware of this.

Giving pihole control of the lighttpd user during setup/config would possibly be the easiest way to achieve that, but I concede not necessarily the only way.

BTW I really appreciate the time the Devs have given to respond to me in this userspace.

[Edit]
I have discovered that www-data is also added to the pihole group during installation.

The result of $cat /etc/group | grep pihole :
pihole:x:994:www-data

Therefore to revert the permssions on /var/log/pihole/pihole.log to 640 for improved security and to ensure that future updates will not overwrite the permissions, it is better to change the supplementary group for pihole from www-data. In my case this was achieved as follows:

Remove user 'www-data' from all supplementary groups.
Depending on the use case, replace with a comma delimited list of
the subgroups which it needs to remain a member of.
usermod -G '' www-data

adds 'pihole' as a supplementary group for asterisk
usermod -G pihole asterisk

Now, the result of $cat /etc/group | grep pihole :
pihole:x:994:asterisk

Then reverting the permissions on the pihole log:
chmod 640 /var/log/pihole/pihole.log

Finally, restart (not reload) lighttpd with:
systemctl restart lighttpd.service

The pihole log now works as expected in the user interface with the correct permissions.
I have also edited the solution above to reflect this.

I would suggest. therefore, that only a minor modification to the pihole installation code is necessary to allow the user to choose the user:group for lighttpd to run as during the setup options, so that the custom user:group can be assigned to /var/log/lighttpd, /var/run/lighttpd, /var/www/html and added to the pihole supplementary group. I would envisage, the default user:group would be chosen by inspecting the existing ownership on /var/www/html and then prompting the user if they want to change it - with a caution that doing so may break any co-existing installation.
[/Edit]