Bug 507406 - Wrong permissions/ownership on /var/lib/php
Wrong permissions/ownership on /var/lib/php
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: lighttpd (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 515169
  Show dependency treegraph
 
Reported: 2009-06-22 12:43 EDT by Herr Irrtum
Modified: 2009-12-08 13:37 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 515169 (view as bug list)
Environment:
Last Closed: 2009-12-08 13:37:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Herr Irrtum 2009-06-22 12:43:33 EDT
Description of problem: 
-----------------------
/var/lib/php (and its contents) belongs to root:apache which makes at least PHP-session management impossible to use under lighttpd


Version-Release number of selected component (if applicable):
--------------------------------------------------------------
php-5.2.9-2.fc11.src.rpm

How reproducible:
-----------------
- Install a "lamp" kind of environment (all with yum)
- - lighttpd as webserver
- - mysql as webserver
- - php as scripting language (also "php-cli")

configure lighttpd to work with PHP (enable line 24 and Line 216-223 in /etc/lighttpd/lighttpd.conf) and do the usual PHP settings in /etc/php.ini (there is a lighttpd setup hint under /etc/php.d).

Start Mysql and then lighttpd i.e. per /etc/init.d/blabla start

Install a PHP program that includes session management i.e. phpMyAdmin from
<http://www.phpmyadmin.net/home_page/downloads.php> under /var/www/lighttpd/phpmybehind (no, don't use YUM for it, I did not test this)

  
Actual results:
---------------
Use your favorite Webbrowser to hook on http://localhost/phpmybehind/setup or just http://localhost/phpmybehind/ and get nothing but an error telling you to check the logs for more infos.

Expected results:
----------------
phpMyAdmin (or another php sessions software) working at least, not showing stupid error messages telling you to check the logs (logs say nothing under lighty btw.)

Additional info:
----------------
The Reason for this is this:
>ll /var/lib/php
drwxr-xr-x  3 root       apache   4096 22. Jun 11:31 php

But lighttpd wants this: 
>ll /var/lib/ |grep php
drwxr-xr-x  3 root       lighttpd   4096 22. Jun 11:31 php

This of course would be again incompatible with other webservers.

So it seems the packagers still think that Apache is the one and only webserver out there (ignoring lightweight servers like lighttpd, nginx, maybe cherokee). At least one gets this impression by looking at the ownerships of webservice-directories. 

To avoid such conflicts it would make much more sense to create a webservice group like "www" or "www-data" or "www-server" like debian, ubuntu and even suse are doing. Any webapplication (like php or lighttpd) should create and use files with this group as owner.

A more general workaround in the current situation would be, not to "re"own -R /var/lib/php (which would work of course too), but adding the (automatically created) user lighttpd to the group apache. Personally I'd find this a bit immoral :) and illogical for a final solution, especially, if there is no Apache on your system. But it works at least.

Regards, Herr Irrtum


Regards, Herr Irrtum
Comment 1 Joe Orton 2009-06-23 04:05:40 EDT
We can't flip about the ownership of the directory post-installation, it would get reset on each upgrade.  Solutions are:

1) use an ACL on the directory.

2) have lighttpd package a separate directory, and have it's invocation of php use that.

Since (1) is not possible AFAIK, (2) is the only solution and it'll have to be done within the lighttpd package.
Comment 2 Jerry Amundson 2009-08-03 00:14:14 EDT
(In reply to comment #0)
> - - mysql as webserver

Or, specifically "as sql server"...

> Install a PHP program that includes session management i.e. phpMyAdmin from
> <http://www.phpmyadmin.net/home_page/downloads.php> under
> /var/www/lighttpd/phpmybehind (no, don't use YUM for it, I did not test this)

Not installing via yum invalidates any "more general workaround".
 
> Expected results:
> ----------------
> phpMyAdmin (or another php sessions software) working at least, not showing
> stupid error messages telling you to check the logs (logs say nothing under
> lighty btw.)
[...]
> To avoid such conflicts it would make much more sense to create a webservice
> group like "www" or "www-data" or "www-server" like debian, ubuntu and even
> suse are doing. Any webapplication (like php or lighttpd) should create and use
> files with this group as owner.

True, and see below.

(In reply to comment #1)
> We can't flip about the ownership of the directory post-installation, it would
> get reset on each upgrade.  Solutions are:
> 
> 1) use an ACL on the directory.
> 
> 2) have lighttpd package a separate directory, and have it's invocation of php
> use that.
> 
> Since (1) is not possible AFAIK, (2) is the only solution and it'll have to be
> done within the lighttpd package.  

3) Use /usr/sbin/alternatives and coordinate all "www-server" packages accordingly. [might as well proactively morph that to www-server80, www-server443, etc. 'cuz you just don't know right now...]

From the Apache perspective:
1. yum install phpMyAdmin [unless lighttpd (or XYZ server) satisfies "httpd" requirement, which seems unlikely.]
2. Try http://localhost/phpMyAdmin/setup/ [actually documented under phpMyAdmin's Quick Install 4.]
3. Note error stuff.
Comment 3 Douglas E. Warner 2009-08-26 09:51:05 EDT
I agree that this is a cross-package problem not just a "lighttpd" or "nginx" problem.  If we actually want to fix this we might want to recommend a feature for F13 since there will need to be a flag day where all the permissions get switched.
Comment 4 Matthias Saou 2009-12-08 13:37:09 EST
Indeed, I'm definitely not going to be making isolated changes to the lighttpd package just to hack around this. It's a more global problem, but I completely disagree with having a common group for all web servers, as it makes much more sense to try and keep multiple web servers on the same system from "sharing" data, that would be a step back in the direction of having all daemons running as "nobody".

I solve the initially reported problem on a regular basis when juggling with apache, lighttpd and nginx : Just create a new directory and point the php.ini you use for your backend to it for sessions. You can also consider using something like memcache or sharedance for storing sessions.

Now that I think of it : The future versions of lighttpd (starting with 1.5) will no longer automatically fork the php processes, you'll need to use spawn-fcgi "manually" (i.e. as a separate service). That's where you have it run as the user you want (nor apache nor lighttpd), use the php.ini you want and store the sessions inside the directory of your choice.

HTH.

Note You need to log in before you can comment on or make changes to this bug.