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_ubject_r:httpd_sys_content_t:s0 .htaccess
-rwxr-xr-x apache nobody system_ubject_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:

 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.

[quote="uplinked, post: 761520"]I tried to fix this unconfined_u error but it did not dissappear after relabelling.[/QUOTE]
The line mentioning "unconfined_u" isn't an error. It just means httpd is running as an [URL="http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Targeted_Policy-Unconfined_Processes.html"]unconfined[/URL] user, which is typical. What's more important is that httpd is running in the httpd_t context, which is proper.

[quote="uplinked, post: 761520"]-rwxr-xr-x apache nobody system_u:object_r:httpd_sys_content_t:s0 index.php[/QUOTE]
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 [URL="http://serverfault.com/"]ServerFault/[/URL], 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.

 

[uplinked]

Hello

First off all, I would like to share the fact that I solved the issue. Thank you for all your guidance. I disabled SeLinux and explicitly disabled the mod_security module in my httpd.conf. This allowed the execution of the POST method, with my current system configuration. So the cgi-scripts I eventually will create should work as well.

However, I ran into a new issue. I cannot access my mysql and existing databases as root. I have granted a new user all privileges but this did not solve my issue when logging in. So, my new issue is security-related in the sense that with SeLinux activated, I can access mysql but not the scripts in my server DocumentRoot, and with SeLinux disabled, I cannot access my mysql-tables to configure the OVD. I understand that disabling mod_security prohibits changes the system files and hence to mysql for security reasons...

Do you happen to know something about this? How do I get access to those tables and databases? It complains that they don't exist when the root user, the new user with all privileges granted or the OVD-scripts try to access them. I can not drop the databases I don't need and the one I plan to use is "not found". I can create new databases, use them but not access them for my OVD-configuration...

Extremely thankful for any help...

 

[misson]

What if SeLinux is enabled but mod_security isn't? It sounds like the latter might be the one causing the problems with POST.

I'll have to look closely at mod_security configuration, but it'll have to wait for a few other things.

Assuming the default action is to block (what's in the config for mod_security?), you'll need a rule to allow POSTing:

SecRule REQUEST_METHOD POST allow

You might need to set the phase the rule is handled in to match the phase of the default action.

If you want to limit where POST is allowed, put the rule in a <Location> directive or chain the rule with a match against REQUEST_URI (though read about the limitations of chaining in mod_security 2; I don't know if they're still present in the newest version).

The above is from a quick skim of the manual; there could very well be more to it.

 

[uplinked]

Thank you... I need a little more time to figure this out though. My OVD does not support SeLinux, so I must disable it. I'll see if I find something out, other else, you are more than welcome to come with a solution! :wink:

I am very grateful for all the help I got...