On Mon, Jun 26, 2017 at 11:51 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Mon, Jun 26, 2017 at 4:44 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>>
>> On Mon, Jun 26, 2017 at 3:40 PM, Gregg Smith <g...@gknw.net> wrote:
>>>
>>> On 6/24/2017 10:02 AM, William A Rowe Jr wrote:
>>>>
>>>> On Sat, Jun 24, 2017 at 12:49 AM, <gsm...@apache.org> wrote:
>>
>>>> While we are at it, why even forking WIN32? If you want to prevent
>>>> APR_CHR files on Windows (or netware or os2 or...) from being
>>>> identified, why wouldn't you simply change the behavior across all
>>>> architectures with a new test case ahead of the != APR_DIR check...
>>>>
>>>> else if (thisinfo.filetype == APR_CHR) {
>>>> ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(00038)
>>>> "Forbidden: %s points to a char stream
>>>> path",
>>>> r->filename);
>>>> return r->status = HTTP_NOT_FOUND;
>>>> }
>>>
>>> Uh yes, but as shown up front the 404 is what we'd get on Unix and forcing
>>> it 404 is what I was doing while improperly.
>>
>> No no no. Unix has CHR devices!!! You can mount them whereever, by
>> convention they all live under /dev/. But that doesn't mean they cannot
>> be found elsewhere. Unix httpd will 403 on these.
>>
>> We should consider if it's worthwhile "hiding" CHR references under some
>> response 404, but ***ONLY*** if we can assert this is a terminal 404, not
>> a recoverable 404. We don't have such a construct yet in httpd, AFAIK.
>>
>>>> Let's please back out that patch entirely and start again by asking
>>>> the question, do we want to treat CHR file paths as not found rather
>>>> than forbidden, and does anyone see an opportunity for httpd's
>>>> core or third party modules to proceed to try to work around that
>>>> file/path leading to potential security blunders? E.g. mod_speling?
>
> So coming back to this core question, what would be the workaround
> to force a 'final determination' of a 404 NOT FOUND in place of any
> security-related 403's? E.g. if we trip over a disallowed symlink, 403,
> if we trip over a CHR file, 403... but admin wants to present a 404
> instead. This must happen after all modules have looked at the 403
> and stepped out of the way, as opposed to trying to substitute content
> in the 404 case.
Why modules couldn't (or shouldn't) recover from such 404s like any other one?
If mod_speling is doing strange things when substituting what it
thinks is a typo (like serving hidden/forbidden files) that's
mod_speling's bug IMHO.
What could be the "security blunders" with 404 vs 403?
Regards,
Yann.
