Apache 2.4 Permission Denied for no apparent reason!

English Network/Internet
#1

Hello everyone,
I just completed a long awaiting upgrade for my home server from openSUSE 13.1 to Leap 42.2 (yes, I did all the upgrades from 13.1–>13.2–>42.1–>42.2)

Everything is OK, with the exception of the Apache Web Server.
All started when I realized that the PHP module was not working. Since I don’t have the time to properly troubleshoot it, I used yast and I enabled PHP5.

Then, hell break loose.
I had a lot of modules that where not loaded (although I had 0 problems with them before) etc.
I limit access on the servers only for a specific subnet (192.168.0.0/24).
With the old Apache 2.2 I used the classic Order deny, allow/allow from 192.168.0.0/24 and everything was fine.
But I decided to use the “correct” directive for 2.4
So, I created a file and I included that file in all my configuration files:

/etc/apache2/vhosts.d/ips.acl


<RequireAll>
    Require ip 192.168.0.0/24
</RequireAll>



<VirtualHost 192.168.0.1:80>
    ServerName mysql.home
    ServerAdmin webmaster@server.home
    DocumentRoot /srv/www/vhosts/mysql
    <Directory /srv/www/vhosts/mysql>
        Include /etc/apache2/vhosts.d/ips.acl
    </Directory>
    DirectoryIndex index.php3 index.php index.html index.htm
    ErrorLog /var/log/apache2/vhosts/mysql.error
    TransferLog /var/log/apache2/vhosts/mysql.access
</VirtualHost>

The loaded modules are:


a2enmod -l
authz_host actions alias authz_groupfile auth_basic authn_file authz_user autoindex cgi dir include log_config mime negotiation setenvif status userdir asis imagemap php5 authn_core wsgi socache_shmcb authz_core mod_auth_digest ssl dav dav_svn

So, the error log is:


[Sat Jul 01 18:03:38.869359 2017] **[authz_core:error[/b]] [pid 23883] [client 192.168.0.3:36999] AH01630: client denied by server configuration: /srv/www/vhosts/mysql/index.php

Obviously, the problem is the authz_core, so, what is wrong with my configuration?**

#2

Ideas;

  • You have a .htaccess file in your vhost or directory above it
  • AppArmor is preventing you from accessing the directory (temporarily disable it and restart Apache to see if this is the case)
  • Try enabling access_compat if none of the above work for you to see if you still have allow/deny somewhere with a2enmod access_compat and restart Apache
#3

Don’t know if relevant, but from what you posted I noticed…

  • You use “mysql” in your filenames when designating website directory and files, I generally avoid that practice to avoid possible collisions with standard running processes (Which could happen if you’re running a mysql or mariadb derver)
  • You specify an include that points to a subdirectory of /etc. Because of the security policies applied to this location, I’d consider it a potential source of permissions problems so requires closer inspection. If the location provides webserver or website configuration information then it needs to be accessible by the apache app. If the location provides website content, then it needs virtualhost access.

Speculating,
TSU

#4

To both posters: No to everything!
I don’t run appArmor, I don’t have SELinux etc

Again, access was not a problem until I run Yast to enable PHP (because I read in a post somewhere here that you cannot just enable with the a2enmod). I am sure that there is a conflict with the basic configuration etc.

What is really concerns me, is the fact that I get a 403 even for the main site.

#5

Well whatever you read, it was wrong - you can most definitely enable PHP via a2enmod. All it does is add it to the list of modules to load, the apache2 php module rpm adds the necessary .conf files.

Without seeing default-server.conf and httpd.conf it’s hard to say what’s been bungled up by the YAST module.

#6

Nowadays,
Every modern Linux distro implements SELinux and a few including openSUSE implement AppArmor as well.
You might say that you don’t create custom modifications for either policy, but at least on openSUSE both exist.
And, this is why you can’t ordinarily deploy website files just anywhere and the safest is to deploy all within the same directory tree and not scattered across your system.

As Miuku says, Apache mods can be loaded either through YaST or a2enmod.

Proper PHP testing should not be to access your main page unless you <now> the entire page is built correctly.
Better and typically recommended is to deploy the standard PHP test page.

TSU

#7

What’s probably missing in your apache config for the host is


# Use own path to webroot
 <Directory /srv/www/htdocs/>
  AllowOverride All
  Require all granted
 </Directory>
#8

Again: SELinux extensions are not even installed.
Anyway, I will open another thread because I removed apache and all configuration files and now I face another problem!

#9

OK, but for the benefit of others…
Unless something changed I’m not aware of, SELinux is implemented by default… possibly in a way you’re not aware of (Many things related to the Linux kernel have changed radically within the past 5 years).

By default, it’s supposed to be a very relaxed policy only enough to protect the core system.

TSU

#10

Based on some light research,
It seems that both SELinux and Apparmoer are implemented through the kernel LVM module, the configuration declares which security framework you wish to choose… There are currently about 4 choices of which SELinux and Apparmoer are two.

openSUSE implements Apparmor, so ordinarily SElinux is not implemented.

This seems to have been published around 2007, and implemented shortly thereafter.

TSU