Bug 515169 - Wrong permissions/ownership on something
Summary: Wrong permissions/ownership on something
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 507406
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-03 04:25 UTC by Jerry Amundson
Modified: 2009-12-13 19:06 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 507406
Environment:
Last Closed: 2009-08-18 12:01:18 UTC


Attachments (Terms of Use)

Description Jerry Amundson 2009-08-03 04:25:40 UTC
+++ This bug was initially created as a clone of Bug #507406 +++

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

--- Additional comment from jorton@redhat.com on 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.

--- Additional comment from jamundso@gmail.com on 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.

[clone to webserver package abc-webserver, etc. ad nauseam :-)]

Comment 1 Joe Orton 2009-08-18 12:01:18 UTC
Using alternatives to flip the directory permissions doesn't make much sense to me.  It would prevent any concurrent use of the directory by any of the users.  You might as well make the directory a %ghost and chown it at startup or something similar.  My take as described before stands; this doesn't affect the httpd package.


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