Silverstripe-framework: SilverStripe requires extra configuration to work with Apache 2.4.X's "Require" directive

Created on 22 May 2019  路  22Comments  路  Source: silverstripe/silverstripe-framework

Affected Version

Apache 2.4.39+

bigfork/silverstripe-oauth-login 2.0.0 SilverStripe logins via OAuth2, using the PHP League's OAuth2 client
dnadesign/silverstripe-populate 2.0.0 Populate your database through YAML files
friendsofphp/php-cs-fixer v2.15.0 A tool to automatically fix PHP code style
lekoala/silverstripe-debugbar 2.0.3 DebugBar for SilverStripe CMS
phpro/grumphp v0.14.3 A composer plugin that enables source code quality checks.
phpunit/phpunit 5.7.27 The PHP Unit Testing framework.
ramsey/uuid 3.8.0 Formerly rhumsaa/uuid. A PHP 5.4+ library for generating RFC 4122 version 1, 3, 4, and 5 universally unique identifiers (UUID).
sensiolabs/security-checker v5.0.3 A security checker for your composer.lock
silverstripe/graphql-devtools dev-master d73f56c Tools to help developers building new applications on SilverStripe芒s GraphQL API
silverstripe/postgresql 2.2.0 SilverStripe now has tentative support for PostgreSQL ('Postgres')
silverstripe/recipe-cms 4.3.0 SilverStripe recipe for fully featured page and asset content editing
silverstripe/recipe-plugin 1.3.0 Helper plugin to install SilverStripe recipes
squizlabs/php_codesniffer 3.4.2 PHP_CodeSniffer tokenizes PHP, JavaScript and CSS files and detects violations of a defined set of coding standards.
symbiote/silverstripe-gridfieldextensions 3.2.1 A collection of useful grid field components
symbiote/silverstripe-queuedjobs 4.4.0 A framework for defining and running background jobs in a queued manner
thenetworg/oauth2-azure v1.4.2 Azure Active Directory OAuth 2.0 Client Provider for The PHP League OAuth2-Client
unclecheese/display-logic 2.0.2 Allows assignment of conditions for display and hide of specific form fields based on client side behavior.

Description

SilverStripe is still using Order, Deny, Allow directives in .htaccess files. This was deprecated with the release of Apache 2.4 and has finally been removed as of 2.4.39 causing SilverStripe to no longer work.

https://httpd.apache.org/docs/2.4/howto/access.html
https://httpd.apache.org/docs/2.4/upgrading.html

Steps to Reproduce

Run SilverStripe with Apache 2.4.39 or later. I'm using OpenSUSE Tumbleweed

Osiris:~ # cat /etc/os-release
NAME="openSUSE Tumbleweed"

VERSION="20190512"

ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20190512"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20190512"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
LOGO="distributor-logo"

Error in Apache Log:
/SDLT/public/resources/.htaccess: Invalid command 'Order', perhaps misspelled or defined by a module not included in the server

Pull requests

affectv4 efformedium impachigh typbug
Source
picture Zaita

All 22 comments

That could be an issue, but please read the upgrading document. At the end:

Invalid command 'Require', perhaps misspelled or defined by a module not included in the server configuration, or Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration - load module mod_access_compat, or update configuration to 2.4 authorization directives.

So you need to load the access_compat module. ( just checked, its still there in the apache2 2.4.39-2.1 rpm on opensuse tumbleweed )

But i do agree that it's good to update the default .htaccess and documentation and start using the new directives.

derkgort picture derkgort on 22 May 2019

Hi Dirk,
Thanks for this. I'm working around it with some docker containers, but good to know its still in Tumbleweed.

S.

Zaita picture Zaita on 22 May 2019

Do you think we should update the Apache config file or the documentation? Would one of you be keen to make a pull request?

robbieaverill picture robbieaverill on 22 May 2019

My preference would be the .htaccess files, as this issue is going to be more common going forward as deployments of apache don't by default enable the compat mode. This is how I discovered it, I did an update in the weekend and tried to deploy SS today.

I unfortunately do not have the knowledge of SS to make a pull request at this point.

Zaita picture Zaita on 22 May 2019

I'm not sure where that .htaccess comes from. If you have a location, maybe in the cms, that would be helpfull.
I could check it and try to make a suggestion on the changes needed. You would probably need a backward-compatible check in there too.

derkgort picture derkgort on 22 May 2019

Are we talking about the assets htaccess file? If so it鈥檚 generated from a .ss template which you could find by searching for the comment in the output file, it鈥檚 ProtectedAdapter.ss or something- sorry I鈥檓 not at a computer right now

robbieaverill picture robbieaverill on 22 May 2019

I found the .htaccess in these repo/files

framework/src/Dev/Install/Installer.php
silverstripe/recipe-core/public/.htaccess

That's something else than @robbieaverill suggested. Am I missing something?

derkgort picture derkgort on 22 May 2019

@derkgort I believe Robbie is referring to this pair of templates which are used to generate .htaccess files in the assets directory:

They don鈥檛 seem to use Order, so should be okay.

kinglozzer picture kinglozzer on 22 May 2019

But the first does use "Deny from all". Which comes from the same depricated module/functions. Good to know.

derkgort picture derkgort on 22 May 2019

FWIW, I enabled mod_access_compat on my installation and it would not allow me to access any of the SS installation files. It seems to have some weird behaviour.

All in all, I have to modify
/public/.htaccess
/public/assets/.htaccess
/public/resources/,htaccess

in order to get it to function.

Zaita picture Zaita on 23 May 2019

What did you change? And what kind of "weird" behaviour?

derkgort picture derkgort on 23 May 2019

In /etc/sysconfig/apache2 I enabled access_compat
Note: /etc/apache2/loadmodule.conf is not used

Then I'd get 403 Access denied across the board. When I changed the .htaccess files to Require all denied to replace the Order/Allow/Deny directives everything works. This is still a bit of a hassle as when the .htaccess files are generated it stops things working (installation etc) until you correct the file manually.

My DocumentRoot is /SDLT/public/

Zaita picture Zaita on 23 May 2019

Just had a read through all the wonderful comments. Here's what I took away. Let me know if I missed anything important.

Summary

  • Apache 2.4 introduced the Require directive to replace Order, Deny, Allow.
  • The Require directive is managed by mod_authz_host. If you want the old directives to keep working you can enable mod_access_compat ... which most Linux distros seem to be doing out of the box.
  • Some Linux distros (OpenSUSE) are starting to disable mod_access_compat by default, which means that the default .htaccess files that ship with your standard SilverStripe install won't work out of the box. People in that boat can solve their problem by either:

    • Re-enabling mod_access_compat

    • Edit their .htaccess files (including asset's htaccess template) to use the newer directive.

Possible next steps

  • Update documentation with guidance for users who want to use the Require directive.
  • Drop official support for Apache 2.2
  • Update installer, recipe-core and recipe-cms to use Require over Deny/Allow

    • This would only affect users starting brand new projects

    • Existing users would still have their old .htaccess files

  • Update assets' HTACCES SS templates to use Require.

    • This would affect anyone upgrading to SS4.5 who didn't customise those files

    • Projects running Apache 2.2 ... or Apache 2.4 with mod_authz_host disabled ... would need override their HTACCESS SS templates.

  • Liaise with OPS to see how this might affect CWP/SSP users.
maxime-rainville picture maxime-rainville on 31 May 2019

Our doc says we support Apache 2.0+ with mod_rewrite and "AllowOverride All" set

I've since rewritten the server requirements, and it no longer spells out which Apache version we support. Because specific statements like that get us into trouble, and don't age well. In the end, we provide some starting points for configuring your hosting environment, but it is not the primary responsibility of a PHP web framework to ensure compatibility with webservers.

Apache 2.2 calling it a "final release" is just another way of saying end of life, meaning they no longer provide security fixes. So this isn't really a discussion. We have a bug in our framework (current version of Apache breaks), and we should fix it to be compatible with the minimum supported version of Apache (2.4).

chillu picture chillu on 18 Sep 2019

Some internal risk assessments on this in https://silverstripe.freshdesk.com/a/tickets/57550.

Here's the section relevant to where we apply those protections in CWP and core modules:

  1. Deny access to *.ss and *.yaml (potentially sensitive config values) everywhere
  2. .htaccess via 3.x defaults: https://github.com/silverstripe/silverstripe-installer/blob/3/.htaccess

  3. public/.htaccess via recipe-core in 4.x: https://github.com/silverstripe/recipe-core/blob/4/public/.htaccess

  4. Deny access to *.php in app/ folder

  5. app/.htaccess via recipe-core in 4.x: https://github.com/silverstripe/recipe-core/blob/4/app/.htaccess

  6. app/.htaccess via CWP 1.x and 2.x installer: https://github.com/silverstripe/cwp-installer/blob/master/app/.htaccess

  7. Deny access to *.php in CWP 1.x (3.x) core modules

  8. framework/.htaccess via https://github.com/silverstripe/silverstripe-framework/blob/3/.htaccess
  9. cms/.htaccess via https://github.com/silverstripe/silverstripe-cms/blob/3/.htaccess
  10. realme/.htaccess via https://github.com/silverstripe/silverstripe-realme/blob/master/.htaccess
  11. ... more modules (need to check)

Note: All supported modules in CWP 2.x (4.x) have shifted to composer-managed directories in vendor/, which prevents access via a highlevel .htaccess file rather than module specific .htaccess files. This new style of writing modules is still opt-in, so there might be modules out there which are still affected (just not ours).

Not affected:

chillu picture chillu on 23 Sep 2019
👍1

Of all modules installed as part of cwp-recipe-kitchen-sink, there are the following .htaccess files:

$ find . -name '.htaccess'
./public/resources/.htaccess
./public/.htaccess
./app/.htaccess
./.htaccess
./vendor/cwp/cwp-installer/public/assets/.htaccess
./vendor/cwp/cwp-installer/app/.htaccess
./vendor/cwp/cwp-installer/.htaccess
./vendor/silverstripe/recipe-core/public/.htaccess
./vendor/silverstripe/recipe-core/app/.htaccess
./vendor/silverstripe/recipe-core/.htaccess
./vendor/silverstripe/recipe-cms/.htaccess
./vendor/silverstripe/vendor-plugin/resources/.htaccess
./vendor/silverstripe/campaign-admin/client/.htaccess

Missing from this list because it's a SilverStripe template that generates a .htaccess file:
./vendor/silverstripe/assets/templates/SilverStripe/Assets/Flysystem/ProtectedAssetAdapter_HTAccess.ss

Not going to patch SS3 modules, they're out of support save for security issues.

For the Common Web Platform (where SS3 is still in a sort of support), SilverStripe Ltd is the vendor and controls that infrastructure. Unless a security issue arises because of the compatibility module I think the value return is overly minimal.

NightJar picture NightJar on 24 Sep 2019

Not going to patch SS3 modules, they're out of support save for security issues.

Yep, fair call. This is only a security issue if a server is misconfigured (not running the Apache compat module which is required for what's now effectively a legacy SilverStripe release)

chillu picture chillu on 24 Sep 2019
👍1

All PR's open, CI green. 馃挌
Calling this done.

Just waiting for mergers before closing #9001 馃挏

image

NightJar picture NightJar on 24 Sep 2019

FYI I tried disabling mod_authz_host on my Ubuntu install just to see what kind of error you would get. I got some pretty nasty warning and Apache wouldn't even restart afterwards. So I think it's a pretty safe assumption that no one out there is running Apache 2.4 without support for Require.

``` $ sudo a2dismod authz_host
WARNING: The following essential module will be disabled.
This might result in unexpected behavior and should NOT be done
unless you know exactly what you are doing!
authz_host

To continue type in the phrase 'Yes, do as I say!' or retry by passing '-f':
```

maxime-rainville picture maxime-rainville on 24 Sep 2019
👍1

Peer reviewed the 2 other PRs.

I'm thinking we probably need to get everythign merge and do a test run on SSP and CWP.

maxime-rainville picture maxime-rainville on 24 Sep 2019

Tested on SSP and CWP. Everything works fine.

maxime-rainville picture maxime-rainville on 25 Sep 2019
🎉1

This issue has been worked on as part of a larger initiative focused on reducing the experience debt of the SilverStripe CMS.

Thank you for taking the time to raise this issue and/ or provide feedback supporting the implementation.

This is an initiative from the teams maintaining the commercially supported module list. If you're interested to read more about this initiative and keep up with our progress have a look at our blog post on experience debt.

maxime-rainville picture maxime-rainville on 25 Sep 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

jakxnz picture jakxnz  路  5Comments
dhensby picture dhensby  路  6Comments
dnsl48 picture dnsl48  路  6Comments
Cheddam picture Cheddam  路  3Comments
ScopeyNZ picture ScopeyNZ  路  5Comments