httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <...@reser.org>
Subject Re: Resolved (sort of): Struggling with AuthMerging
Date Sat, 03 Aug 2013 06:05:09 GMT
On Fri, Aug 2, 2013 at 8:24 PM, Mikhail T. <mi+thun@aldan.algebra.com> wrote:
> The modules in your examples deliberately use the authz mechanism to
> generate different output based on the results. But what is doing it in the
> case I describe -- where the generated content is exactly the same?

Obviously nothing is doing a subrequest to validate the auth, they're
doing sub-requests to fulfill the original request.  httpd is doing
the auth because it's the right thing to do from a security
perspective.  The generated content is not the same.  The main request
has no generated content it's essentially a redirect, it just happens
to be handled internally.

> Why would anyone want to provide distinct authorization rules to /foo/ and
> /foo/index.html, for example? What is a possible use-case?

They are different paths they may have different auth rules.  httpd
can't assume that it'll be okay.  Keep reading and I'll explain why.

> Likewise, why would anyone configure mod_fastcgi to hand off processing of
> PHP-files to FPM:
>
> FastCGIExternalServer   /usr/sbin/php-fpm -socket /var/run/fpm/main.sock
> AddHandler              php-fastcgi     .php
> Action                  php-fastcgi     /php-fpm
> ScriptAlias             /php-fpm        /usr/sbin/php-fpm
>
> but need the /php-fpm/foo/ to have authorization rules different from those
> of /foo/?

You don't seriously expect the auth system to know all of those
intricacies?  It has no idea why the subrequest is being made it just
knows there's a request to process.  Even if it did know why the
subrequest is being made the variety of authz systems doesn't allow
you to make assumptions like the above.

In 2.4.x there's the new provider architecture that at least lets you
optimize away subrequests that have the same conf.  But the modules
have to say it's ok because if the modules are handling path based
matching on their own then even httpd has no idea if /foo and
/foo/index.html have the same configuration.  mod_authz_svn is an
example of such a module that could not use the CONF flag (but at this
time it isn't using the new provider system and is still using the old
hooks system).  given that there are authz modules like this you can't
even make the argument that we can ever assume that authz isn't
necessary

If all of your authz/authn providers are using the CONF flag and
you're getting duplicated authz processing for subrequests that have
the same conf applied to them then it's possible there's a bug here.
I haven't ever specifically looked at this code so I can't tell you
how it works, all I can do is tell you what the documentation says it
does.  Unfortunately I have other priorities right now so I don't
really have the time to go down that rabbit hole and find out if there
is a bug that's causing extra authz calls.

Any attempt to optimize when authn/authz happens on subrequests is
going to have to be done very carefully since you really can't make
any assumptions about what should be allowed.  I realize that in your
specific case that seems absurd but the httpd core code supports use
cases that are very different from yours.

Mime
View raw message