Please advice... OS: Fedora... Problem: httpd config

[uplinked]

Hi

I have installed and configured Apache on Fedora. I am trying to serve a virtual desktop solution. I have chmoded -R 777, chown apache to the root, allowed +ExecCGI, chcon to cgi_exec_t. Still, I get a 403 forbidden error when trying to configure the database (which is working). It is the POST that gets forbidden on the configuration files, not the GET. I have tried curl, it shows 403 forbidden for POST, although I have <limit POST> to allow.

I am out of ideas what the problem might be... Please advice.

SeLinux is disabled.

[Brandon]

Depending on how you have apache setup, you want the files chowned to the 'nobody' or 'apache' user, and do not set the files to 777, 755 should be enough.

[uplinked]

This is not the sharp mode, just test mode in a closed network. What I meant was that not even chmod 777 allows the configuration through the post method. I have tried both apache and www users, without any luck. Any other ideas on what I might have missed? I really cannot find the reason to this 403 forbidden. I will try the nobody... Thank you.

Btw, I added all users (apache and www) to the apache group, which is chowner of the files...

[Brandon]

Find and check your error_log, the reason will be in there.

[uplinked]

Nothing shows in the error log, all I get is this 403 on POST in the access log and Preferences:Fail in the virtual desktop log. It must be the permissions somehow, as I had it up running before. But it won't work this time... I will try the nobody though and return. Thanks for your time!

---------- Post added at 06:50 PM ---------- Previous post was at 06:19 PM ----------

I think I also had a headers already sent warning... Could this be it?

[misson]

If you comment out the <Limit POST> directive to make it accessible to all, does it work? If so, what is your <Limit POST> section? Do any other pages in the folder (assuming there are any) generate a 403 response when posting to them? If necessary, create a simple script in the same folder and request it with both a GET and a POST. Report the results here.

ExecCGI should only be necessary if using mod_cgi. What handler are you using for the virtual desktop scripts?

chcon to cgi_exec_t [...] SeLinux is disabled.

Shouldn't the security context be "httpd_sys_script_exec_t"? Of course, if SELinux is disabled, it shouldn't matter.

I think I also had a headers already sent warning... Could this be it?

If you get a 403 response for a script resource, the request was never handed off to the script. A warning that headers were sent means that the request made it to that particular script. I very much doubt that early output from the script is somehow causing a 403.

[uplinked]

Hello

Thank you both for your support to begin with... Well, I am reporting back the following:

I enabled SELinux.

The httpd config contains the following of interest for the document root:

<Directory />
Options +ExecCGI +Indexes FollowSymLinks
AddHandler cgi-script .cgi
AllowOverride Limit
Order Allow,Deny
Allow from all
Allow from 127.0.0.1
</Directory>

My .htaccess only contains the following:

<Limit GET POST>
Order allow,deny
Allow from all
Allow from 127.0.0.1
</Limit>

- I tried a simple contact php-script as you suggested. I still get POST errors. I got the same results as with the virtual desktop files. My access_log looks like this:

127.0.0.1 - - [22/Nov/2010:15:40:20 +0100] "POST /index.php HTTP/1.1" 403 312 "http://localhost/index.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102704 Fedora/3.0.15-1.fc10 Firefox/3.0.15"
127.0.0.1 - - [22/Nov/2010:15:40:41 +0100] "GET /index.php HTTP/1.1" 200 2390 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102704 Fedora/3.0.15-1.fc10 Firefox/3.0.15"
127.0.0.1 - - [22/Nov/2010:15:40:41 +0100] "GET /index.php HTTP/1.1" 200 2390 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102704 Fedora/3.0.15-1.fc10 Firefox/3.0.15"
127.0.0.1 - - [22/Nov/2010:15:40:41 +0100] "GET /index.php HTTP/1.1" 200 2390 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102704 Fedora/3.0.15-1.fc10 Firefox/3.0.15"
127.0.0.1 - - [22/Nov/2010:15:40:41 +0100] "GET /index.php HTTP/1.1" 200 2390 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102704 Fedora/3.0.15-1.fc10 Firefox/3.0.15"
127.0.0.1 - - [22/Nov/2010:15:40:44 +0100] "POST /index.php HTTP/1.1" 403 312 "http://localhost/index.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102704 Fedora/3.0.15-1.fc10 Firefox/3.0.15"

The error_log:

[Mon Nov 22 15:40:38 2010] [notice] caught SIGTERM, shutting down
[Mon Nov 22 15:40:39 2010] [notice] core dump file size limit raised to 4294967295 bytes
[Mon Nov 22 15:40:39 2010] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0
[Mon Nov 22 15:40:40 2010] [notice] ModSecurity for Apache/2.5.10 (http://www.modsecurity.org/) configured.
[Mon Nov 22 15:40:40 2010] [notice] Original server signature: Apache/2.2.14 (Fedora)
[Mon Nov 22 15:40:40 2010] [notice] Digest: generating secret for digest authentication ...
[Mon Nov 22 15:40:40 2010] [notice] Digest: done
[Mon Nov 22 15:40:41 2010] [notice] mod_python: Creating 4 session mutexes based on 150 max processes and 0 max threads.
[Mon Nov 22 15:40:41 2010] [notice] mod_python: using mutex_directory /tmp
[Mon Nov 22 15:40:41 2010] [notice] Apache/2.2.14 (Unix) DAV/2 mod_auth_kerb/5.3 mod_auth_pgsql/2.0.3 mod_ssl/2.2.14 OpenSSL/0.9.8g PHP/5.2.9 mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations

I tried to fix this unconfined_u error but it did not dissappear after relabelling.

[Mon Nov 22 15:40:39 2010] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0

Any idea why?

Also, my last change of ownership (besides nobody:nobody which didn't work either...) looks like this for the test file, in which I solely used the GET and POST methods:

-rwxr-xr-x apache nobody system_u:object_r:httpd_sys_content_t:s0 .htaccess
-rwxr-xr-x apache nobody system_u:object_r:httpd_sys_content_t:s0 index.php

I am still getting the 403 forbidden. I don't know which script is used by the virtual desktop solution, the error is in the POST. I allowed cgi to be sure since I didn't have the time to go through all the files.

Any new ideas please why I get 403 on POST?

Thank you in advance!

[misson]

What virtual desktop are you using? I suspect the problem lies there rather than with Apache or SELinux settings, given that GET works while POST doesn't, and that the virtual desktop logs an error (which shows it's processing the request). There's still a possibility SELinux could be involved.

I enabled SELinux.

It's better to try to get everything working with SELinux disabled, so you can rule it out as a cause.

<Limit GET POST>
    Order allow,deny
    Allow from all
    Allow from 127.0.0.1
</Limit>

The <Limit> is fine. Moreover, GET and POST are configured the same. Similarly, permission and ownership issues would affect GET and POST requests equally.

Note: [CODE] is more appropriate than [QUOTE] for settings. Also, when quoting someone, anything in [QUOTE]s in their post are stripped out.



If you're using mod_php to handle PHP, whether or not ExecCGI is set won't matter. It's only important when running PHP in CGI or FastCGI mode. That the index.php is in the httpd_sys_content_t context strongly suggests you're using mod_php.

I tried to fix this unconfined_u error but it did not dissappear after relabelling.

The line mentioning "unconfined_u" isn't an error. It just means httpd is running as an unconfined user, which is typical. What's more important is that httpd is running in the httpd_t context, which is proper.

-rwxr-xr-x apache nobody system_u:object_r:httpd_sys_content_t:s0 index.php

As previously suggested, try placing the scripts in the httpd_sys_script_exec_t context. They could be failing when SELinux is enabled because the script is trying to access something it doesn't have access to. You might need to find out what that is, then place it in the httpd_sys_content_t context.

The time period for the error_log excerpt doesn't include the POST requests. You mentioned that there was nothing in the error log for earlier failed POSTs; does this still hold true for the POSTs logged above (22/Nov/2010:15:40:20 and 22/Nov/2010:15:40:44)?

You might want to ask a question on ServerFault/, if it doesn't turn out to be the virtual desktop.

[uplinked]

Thank you for your explanations... However, I had SELinux enabled now for more detailed trouble-shooting in the logs. My virtual desktop is Ulteo OVD. It must run with SeLinux disabled. Yet, even with SELinux disabled, I still get the 403. Even after removing the SELinux module or after setting all content to httpd_sys_script_exec_t and then removing SeLinux completely. I kept it on the server, in the disabled mode in the case I need to relabel.

Yes, the logs are as published above... No POST in the error_log, just access_log.

I had this OVD configured and running once before, but it won't work now. I went through a lot of trouble that time as well. It is different now though... The results published above are the outcome of a simple php.script, a contact form with GET for the fields and POST set to PHP_SELF. This shouldn't be the outcome of a simple POST request... yet it is. I posted this here in the case you guys had experienced this at home...

The log from the OVD does not behave differently at all. The same 403 on POST. I will try to locate it. It complains about not having access to some .js files and some .php-files which it needs for its partial configuration before summing it up in sum-config.php. But the files should be accessible. The same applies to the contact script.

Is there a chance that I could get to read a complete http.conf file which allows the simple execution of a php-contact script to see if I missed something?

Well, until then, I'll keep trying. If anyone successfully installs this OVD-software on a Fedora server, please let me know and share your success...

[misson]

The results published above are the outcome of a simple php.script, a contact form with GET for the fields and POST set to PHP_SELF. This shouldn't be the outcome of a simple POST request... yet it is. I posted this here in the case you guys had experienced this at home...

Duh. So we can mostly rule out v. desktop settings. Next thing to test is to create a CGI script in the same folder (since it's configured to run them) and try GETting it and POSTing to it. This should tell us if the issue lies with the PHP module or elsewhere.

The log from the OVD does not behave differently at all. The same 403 on POST. I will try to locate it. It complains about not having access to some .js files and some .php-files which it needs for its partial configuration before summing it up in sum-config.php. But the files should be accessible. The same applies to the contact script.

Are the JS accessed server side? You can use the POSIX functions to get the real and effective user IDs the script process is running as, then make sure that that user has appropriate access to the files mentioned in the log. You might want to throw in a file_exists and is_readable to check within the script.

Is there a chance that I could get to read a complete http.conf file which allows the simple execution of a php-contact script to see if I missed something?

The httpd configuration file templates are available via SVN. Google lists plenty of example httpd.conf for PHP. I don't know of any in particular that would be helpful for you to look at.