On 03 Aug 2012, at 9:25 AM, Stefan Fritsch wrote:
>> I have a config like this using httpd v2.4, in an effort to
>> password protect each person's userdir:
>>
>> <RequireAll>
>> Require valid-user
>> Require expr %{note:mod_userdir_user} == %{REMOTE_USER}
>> </RequireAll>
>>
>> Hit it with a browser, and instead of 401 Unauthorized I'm getting
>> 403 Forbidden instead, which prevents the basic authentication
>> from kicking in and the user is denied.
>>
>> The log however shows something odd - despite the RequireAll
>> directive being used, which implies AND behaviour, which in turn
>> implies that require lines should be parsed until the first one
>> fails and then the parsing should stop, both require lines are
>> being evaluated even though the first line failed, and the result
>> of the second require line is being sent instead.
>
> This works as designed. Authentication will only be triggered if the
> end result depends on a valid user being present. The reason is to
> avoid a password dialogue if the access will be denied anyway.
This breaks basic authentication though, because basic auth relies on that
initial 401 Unauthorized to tell the client that a password is required. In
this case, access would have been approved, not denied, but the client never
got the opportunity to try log in as it was forbidden from the outset.
Right now, I cannot get aaa to work in either a browser or in the webdav client
for MacOSX with two require lines. In both cases, the user is forbidden
immediately with no opportunity to log in.
>> In theory, in the RequireAll situation, require directives should
>> be parsed until one fails, and the result of that failure returned
>> to the client. All further require lines should be ignored as is
>> standard behaviour for AND implementations. In the example above,
>> the "authorization result of Require valid-user : denied (no
>> authenticated user yet)" part should prevent the "authorization
>> result of Require expr %{note:mod_userdir_user} == %{REMOTE_USER}:
>> denied" part from being attempted at all.
>>
>> Can someone check whether my thinking is correct?
>
> I guess your approach would have been valid, too. But it causes other
> problems since the user cannot influence the order in which require
> directives are evaluated if AuthMerging is "or" or "and".
In theory the evaluation should be done in the order that the directives appear
in the config file.
> One could
> have solved that with some additional directives like "AuthMerging or
> prepend", etc., but that would get rather complex if one wants to keep
> the full flexibility. I could imagine cases where additional require
> lines would need to be evaluated in the middle of the inherited lines.
How does inheritance work now?
> For 2.4.x, we are now stuck with the current behavior. For 2.6/3.0, we
> may of course consider to change it, if the alternative is better.
Right now from what I can see the RequireAll directive isn't working at all, so
to fix it in v2.4 would just be a bugfix.
> 2.4.3 will give "require expr" some special casing for REMOTE_USER
> that makes your use case work (see r1364266). PR 52892 has a
> workaround that works with 2.4.2, too.
>
> If the special case for REMOTE_USER is not enough, one could add a
> trigger_authn function that allows the same behavior for arbitrary
> variables. E.g.
>
> Require expr %{note:mod_userdir_user} ==
> trigger_authn(%{AUTHZ_VAR_FOO})
I'm not convinced. Both AND and OR have behaviour dictated by the principle of
least astonishment, and I think it would be better for end users for the
behaviour to match what they expect, rather than try to second guess what the
end user wants with special cases.
Regards,
Graham
--
smime.p7s
Description: S/MIME cryptographic signature
