DevHeads.net

Spurious access denied errors

Dear list,

I've installed and configured mediawiki as follows (on top of default
Ubuntu 16.04 Apache/2.4.18 installation):

*Everything works*, i.e. client successfully receive all pages with
appropriate HTTP statuses in both client and Apache access log. However,
for each request like /wiki/test I see the following extra message in
error.log:

If I remove <Directory /var/www> clause, these messages disappear. They
trigger fail2ban and are generally confusing. What may be causing them
and how to make them stop?

Comments

Re: Spurious access denied errors

By Yehuda Katz at 02/09/2018 - 09:58

At first glance, something in your browser is probably requesting the page
/test. Since it doesn't correspond to any of your alias statements, it hits
the DocumentRoot which you have denied access to.

Is there a corresponding entry in your access log?

- Y

Sent from a device with a very small keyboard and hyperactive autocorrect.

Dear list,

I've installed and configured mediawiki as follows (on top of default
Ubuntu 16.04 Apache/2.4.18 installation):

DocumentRoot /var/www/html
*Everything works*, i.e. client successfully receive all pages with
appropriate HTTP statuses in both client and Apache access log. However,
for each request like /wiki/test I see the following extra message in
error.log:

[Fri Feb 09 09:35:25.368731 2018] [authz_core:error] [pid 695] [client
If I remove <Directory /var/www> clause, these messages disappear. They
trigger fail2ban and are generally confusing. What may be causing them and
how to make them stop?

Re: Spurious access denied errors

By Marat Khalili at 02/09/2018 - 11:30

There's no entry in access log, and the problem is easily reproduced
with curl/wget. There's only one request visible in tcpdump. I've also
confirmed that excluding proxy does not fix the problem.

On the other hand, I don't see same problem on bare Apache installation
serving only static files. Can Mediawiki PHP create some internal
requests? How can I debug this?

Re: Spurious access denied errors

By Daniel at 02/09/2018 - 15:09

Probably because you are essentially denying access to documentroot
and this path is checked for all requests.

Add a
<Directory /var/www/html>
Require all granted
</Directory>

or change documentroot to a directory you can give access even if it's
an empty directory to get rid of those messages or change the
documentoot to something else.

Denying access to documentroot by default is not...

2018-02-09 16:30 GMT+01:00 Marat Khalili < ... at rqc dot ru>:

Re: Spurious access denied errors

By Marat Khalili at 02/09/2018 - 15:21

Looks like your are right, but why? What if there's a file there? What if there's a script there? A device file or a symbolic link to one?

I will do like you advise, but would still like to learn what's going on.

Re: Spurious access denied errors

By Daniel at 02/11/2018 - 05:56

what if?

The way I see it you are the admin and supposed to set up a correct
documentroot, there are not "what if" for things under your control
imo.

About the internals probably some knowledgeable dev can tell you much
better than I, but afaik DocumentRoot is always checked because it is
"where all starts", that is, by definition DocumentRoot is where
apache starts looking when serving requests, all things you "mount"
such as aliases are "mounted" on top/after/relative to it, so just
take better care where you point the documentroot because it is
important.

2018-02-09 20:21 GMT+01:00 Marat Khalili < ... at rqc dot ru>:

Re: Spurious access denied errors

By Eric Covener at 02/11/2018 - 11:25

On Sun, Feb 11, 2018 at 4:56 AM, Daniel < ... at gmail dot com> wrote:
The error may come from a subrequest, which is an internal feature
where a module like mod_dir might use to probe if some URL exists.

Re: Spurious access denied errors

By Marat Khalili at 02/13/2018 - 11:52

Thank you for the suggestion. I tried to disable mod_dir, fortunately
mediawiki seem to work fine without it, but the error is still there.
Allowing access to DocumentRoot of course solves the problem, but I'm
still curious...