[squid-users] authenticate_ip_ttl does not work

[Amos Jeffries]

On 14/05/2016 12:26 a.m., asakura at ioc.dnp.co.jp wrote:
> Hello,
> 
> Thank you always for your kind support.
> 
> I testing squid-3.5.19 "max_user_ip/authenticate_ip_ttl" feature.
> but, access control not work well.
> (Value of authenticate_ip_ttl is not enable)
> 
> I investigating, and tried to change as follows.
> 
> src/auth/User.cc
> ----
> # diff User.cc.org User.cc
> 287c287
> <             ipdata->ip_expiretime = squid_curtime;
> ---
>>             ipdata->ip_expiretime = squid_curtime + ::Config.authenticateIpTTL;
> ----
> 
> Is this would be correct change?

No. That particular data cache is one in Squid that works on a very
weird staleness orientation rather than freshness.

Caches that work on freshness behave like one would expect. Things start
out fresh and grow towards some TTL 0 point where the flip to being
stale and can be removed or replaced.

But these weird staleness oriented things start out at some origin point
in time (squid_curtime) and just continue to get more and more stale.
Operations that need to be done on them can use multiple and different
TTL offsets, which change over time (for example on reconfigure) without
affecting the cached objects. It is up to the logic doing that operation
to check the staleness against the right TTL.

You can see this in Auth::User::cacheCleanup() which applies
authenticate_ip_ttl to see what can be erased. Compared to the
Auth::User::absorb() which compares two lists of objects against each
other and drops from one list anything that is not brand new (current
second).

I suspect bugs you are seeing are in that absorb operation since it is
timing-critical and happens with an async delay in the middle of the
list being created and method happening.


If you want to help out with that whole mess there, please discuss
intended changes on squid-dev mailing list where the other dev are sure
to see your proposals.


Amos