[squid-dev] [PATCH] Fix 'miss_access' and 'cache' checks when no ACL rules matched

[Amos Jeffries]

On 13/05/17 05:24, Eduard Bagdasaryan wrote:
>
> On 12.05.2017 07:54, Amos Jeffries wrote:
>>  Also going through the process to deprecate cache directive formally 
>> might be worth beginning - most old uses should be a straight rename 
>> to store_miss, but some will be send_hit or a mix of the two. Just 
>> adding a debugs statement to that effect on startup, reconfigure, and 
>> -k parse should do for a while.
>
>
> If there are plans about deprecating 'cache' directive, good, but it is a
> possibly a future work which is unrelated here.  BTW, I think we can't 
> simply
> 'rename' it to 'store_miss' or a mix of the two directives because 
> 'cache'
> directive supports both fast and slow checks, but both 'store_miss' and
> 'send_hit' only fast ones.  Probably I miss or do_not_understand 
> something
> important.

I meant that many admins would simply be able to do so.

It is the remaining cases that are problems, both for removal and for 
changing how the directive behaves.



> On 12.05.2017 17:32, Amos Jeffries wrote:
>> That r14984 was itself carefully designed to _revert_ unintentional 
>> side effects hostVerify had on cache directive behaviour. Your patch 
>> is reverting those DUNNO occurances back to the code which had many, 
>> many complaints.
>
> I looked through bug 3940 discussion but have not found any connection 
> between
> ACCESS_DUNNO/ACCESS_AUTH_REQUIRED/checkNoCacheDone() and
> hostHeaderVerify()/hostHeaderVerifyFailed() methods. Yes, all these 
> methods
> may change RequestFlags flags, and that what
> fix of r14984 is about, but how, roughly, hostHeaderVerifyFailed() may 
> cause
> ACCESS_DUNNO? In other words, I have not found any hints about your 
> primary
> change ACCESS_ALLOWED into ACCESS_DENIED: no in the patch preamble, no
> in the bug discussion. I assume there are another threads/bugs where 
> this change
> probably was discussed. If so, could you please post such references 
> here?

Sorry, this is one of those situation where we are obfuscating a 
vulnerability issue.

Amos